Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable automatic session tracking by default #314

Merged
merged 21 commits into from
Jun 12, 2018

Conversation

fractalwrench
Copy link
Contributor

@fractalwrench fractalwrench commented May 10, 2018

Goal

Enables automatic tracking of sessions by default, and adds a new API for setting the notify/session endpoints which deprecates the old method.

Design

This should prevent the unintentional scenario where a user sets the notify endpoint with a sessions endpoint.

Changeset

Added

config.setEndpoints(String notify, String sessions)

Changed

Deprecation notice for:
config.setEndpoint
config.setSessionsEndpoint
client.setEndpoint

Manifest meta-data parsing logic

Tests

An additional Mazerunner test for ensuring a session is automatically tracked on app launch, and unit tests for ensuring:

  • Setting autoCaptureSessions to false prevents a session from being sent at app load
  • Manually calling sendSession() sends a session regardless of the state of autoCaptureSessions
  • Manually calling sendSession() with endpoint configured but not sessionsEndpoint issues a warning and does not send a session

This doesn't automatically test that configuring endpoint without session endpoint logs a warning, as this is difficult to achieve on Android.

Discussion

Outstanding Questions

The deprecated options are not aliased onto the new API - I believe this is ok.

N.B. CI may currently fail due to unrelated flaky tests which are addressed in a separate PR.

Review

For the submitter, initial self-review:

  • Commented on code changes inline explain the reasoning behind the approach
  • Reviewed the test cases added for completeness and possible points for discussion
  • A changelog entry was added for the goal of this pull request
  • Check the scope of the changeset - is everything in the diff required for the pull request?
  • This pull request is ready for:
    • Initial review of the intended approach, not yet feature complete
    • Structural review of the classes, functions, and properties modified
    • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

  • Consistency across platforms for structures or concepts added or modified
  • Consistency between the changeset and the goal stated above
  • Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
  • Usage friction - is the proposed change in usage cumbersome or complicated?
  • Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
  • Concurrency concerns - if components are accessed asynchronously, what issues will arise
  • Thoroughness of added tests and any missing edge cases
  • Idiomatic use of the language

@fractalwrench fractalwrench changed the base branch from master to next May 10, 2018 12:31
@fractalwrench fractalwrench requested a review from a team May 10, 2018 12:35
@coveralls
Copy link

Coverage Status

Coverage increased (+0.6%) to 77.014% when pulling 3334063 on enable-session-tracking into f76d408 on next.

@coveralls
Copy link

coveralls commented May 10, 2018

Coverage Status

Coverage increased (+0.3%) to 77.756% when pulling 6432b4c on enable-session-tracking into 48a807f on next.

Copy link
Contributor

@kattrali kattrali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Short and sweet 🎉

autoCaptureSessions = false;
}
this.endpoint = notify;
this.sessionEndpoint = sessions;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if invalidSessionsEndpoint is true, then shouldn't this be set to null? Whether to send a session could then be determined by whether the endpoint is null rather than adding a new property.

It would also reduce the odds of unexpected behavior if Bugsnag.setAutoCaptureSessions() is called after configuration.

@fractalwrench
Copy link
Contributor Author

Refactored to check that sessionEndpoint is null rather than an adding an additional boolean flag, when starting a new sessions.

Also, here is the related Docs PR: https://github.com/bugsnag/docs.bugsnag.com/pull/720

@fractalwrench fractalwrench requested a review from a team May 11, 2018 16:12
}

config.setSendThreads(data.getBoolean(MF_SEND_THREADS, true));
config.setPersistUserBetweenSessions(
data.getBoolean(MF_PERSIST_USER_BETWEEN_SESSIONS, false));
config.setAutoCaptureSessions(data.getBoolean(MF_AUTO_CAPTURE_SESSIONS, false));

if (data.containsKey(MF_AUTO_CAPTURE_SESSIONS)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the advantage of this over the previous with the default set to true?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method no longer requires any knowledge of whether sessions should be automatically captured or not, and relies on Configuration instead to specify a sensible default.

if (invalidSessionsEndpoint) {
Logger.warn("The session tracking endpoint has not been set. "
+ "Session tracking is disabled");
autoCaptureSessions = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this require a this. prefixing it as below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not necessarily required but I think that's a good suggestion as it makes the semantics clearer that autoCaptureSessions is a field, and would be more consistent with the rest of the method.

} else {
this.sessionEndpoint = sessions;
}
this.autoCaptureSessions = !invalidSessionsEndpoint;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is being set in the if/else above, does it need to be set again here? It may end up being set to true after it's been manually disabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both are not required, I've removed autoCaptureSessions = false

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There could be an issue where someone sets autoCaptureSessions to false, then inputs a valid sessions endpoint. The:

this.autoCaptureSessions = !invalidSessionsEndpoint;

would then incorrectly set the autoCaptureSessions back to true, overriding the user's configuration. Is that a possibility?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point - I've added an explicit test case for this scenario.

@@ -64,6 +64,11 @@
* @param user the session user (if any)
*/
void startNewSession(@NonNull Date date, @Nullable User user, boolean autoCaptured) {
if (configuration.getSessionEndpoint() == null) {
Logger.warn("The session tracking endpoint has not been set. "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should have mentioned this earlier, sorry - Should this warning be a one-time thing? We could end up adding a lot of logger noise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Logger class will automatically disable itself in production if that's a concern? The default implementation of session tracking waits at least 30 seconds before starting a new session on Android, so for the default use case I'd imagine this message would only be logged once or twice.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that's ok, are there any similar cases already present in the notifier?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is somewhat similar.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean for the logging repeatedly when in debug mode?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Cawllec it's not particularly easy to test log messages in Android unfortunately

Copy link
Contributor

@martin308 martin308 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added one suggestion and one question

*
* @throws IllegalArgumentException if the notify endpoint is empty or null
*/
@SuppressWarnings("ConstantConditions")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth adding a comment on the reasoning behind suppressing specific warnings

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added an inline comment

*/
@SuppressWarnings("ConstantConditions")
public void setEndpoints(@NonNull String notify, @NonNull String sessions)
throws IllegalArgumentException {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a big change in behavior? The other methods on configuration just accept whatever was set

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC the design doc for this change states that we should throw an exception if notify is not a valid URL, and log a warning if sessions is not. The rationale being that the notifier can't really do anything useful if the notify endpoint has been misconfigured, but can still send errors if session tracking is not in use. I think it makes sense to fail fast in this instance if a programmer supplies an invalid value.

@Cawllec
Copy link
Contributor

Cawllec commented May 17, 2018

Looks good, just the CI that's not working ATM.

@fractalwrench
Copy link
Contributor Author

CI has passed now (the test flakiness seems to be back on Travis)

@fractalwrench fractalwrench requested a review from a team May 17, 2018 13:46
Copy link
Contributor

@Cawllec Cawllec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM assuming @martin308 and @kattrali are now happy

*
* @throws IllegalArgumentException if the notify endpoint is empty or null
*/
@SuppressWarnings("ConstantConditions") // ignore checkstyle nullability warnings
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking more along the lines of the reasoning behind suppressing it. I'm not sure what this does exactly but here is a possibly terrible example "Suppress this warning as we know that the "notify" parameter can be null due to this amazing reason... but we can ignore it because of some other scenario..."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed this annotation as it appears it's no longer needed. I believe it was originally included because a null check was performed on notify and sessions, which are annotated as non-null. Checkstyle picks up the nullability annotation, but unfortunately this isn't enforced by the compiler for Java, so it made sense to perform a null check.

This code now uses TextUtils.isEmpty, which also checks for an empty string along with null, which isn't a constant condition.

CHANGELOG.md Outdated
@@ -1,5 +1,13 @@
# Changelog

## 4.X.X (TBD)

**Note**: this release alters the behaviour of the notifier to track session automatically. If you
Copy link
Contributor

@bengourley bengourley May 31, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm reusing this copy for the js changelog and noticed a little typo:

- track session automatically
+ track sessions automatically

@fractalwrench fractalwrench merged commit 9ec00e2 into next Jun 12, 2018
@fractalwrench fractalwrench deleted the enable-session-tracking branch June 12, 2018 09:26
lemnik pushed a commit that referenced this pull request Jun 2, 2021
…scenarios

Create additional E2E scenarios for Unity SO file upload
rich-bugsnag pushed a commit that referenced this pull request Sep 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants