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

Fixes #231

Merged
merged 17 commits into from
Jan 26, 2018
Merged

Fixes #231

merged 17 commits into from
Jan 26, 2018

Conversation

kattrali
Copy link
Contributor

Reduces complexity of locking/synchronization, which reduces scope of ANRs

@@ -48,7 +48,7 @@ public int compare(File lhs, File rhs) {
void flushOnLaunch(final ErrorReportApiClient errorReportApiClient) {
final List<File> crashReports = findLaunchCrashReports();

if (crashReports.isEmpty() && config.getLaunchCrashThresholdMs() > 0) {
if (crashReports.isEmpty() && config.getLaunchCrashThresholdMs() == 0) {
flushAsync(errorReportApiClient); // if disabled or no startup crash, flush async
Copy link
Contributor Author

Choose a reason for hiding this comment

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

- if (crashReports.isEmpty() && config.getLaunchCrashThresholdMs() > 0) {
+ if (crashReports.isEmpty() && config.getLaunchCrashThresholdMs() == 0) {
  // if disabled or no startup crash, flush async

When launchCrashThresholdMs is greater than 0, any stored crashes which occurred before the threshold elapsed since launch would be sent immediately, correct? So launchCrashThresholdMs equal to 0 is disabling sending crashes on launch.

Breaking this one down,

- if (crashReports.isEmpty() && config.getLaunchCrashThresholdMs() == 0) {
+ boolean neverFlushOnLaunch = config.getLaunchCrashThresholdMs() == 0;
+ boolean noStartupCrashes = crashReports.isEmpty();
+ if (noStartupCrashes && neverFlushOnLaunch) {
  // if disabled or no startup crash, flush async

shouldn't this be an "or" instead?

- if (noStartupCrashes && neverFlushOnLaunch) {
+ if (neverFlushOnLaunch || noStartupCrashes) {

Copy link
Contributor

Choose a reason for hiding this comment

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

This makes sense to me.

writer.name("duration").value(getDuration());
writer.name("durationInForeground").value(sessionTracker.getDurationInForeground(System.currentTimeMillis()));
writer.name("duration").value(getDurationMs()/1000);
writer.name("durationInForeground").value(sessionTracker.getDurationInForegroundMs(System.currentTimeMillis())/1000);
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 is not introduced in this changeset, but these values are different if the session is delivered immediately vs retried after a long attempted network request.

if (activityStarting) {
long noActivityRunningForMs = nowMs - activityLastStoppedAtMs.get();

//TODO:SM Race condition between isEmpty and put
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 didn't find a real-world case for this, even programmatically switching foreground activities rapidly.

snmaynard and others added 3 commits January 24, 2018 15:50
startFirstSession tracks an automatic-style session if one has not yet 
been captured, recording the current activity.

This avoids:
* not reporting the current session because an activity is already active
* starting a session manually which will result in duplication when a
  new activity is started
Async.run(new Runnable() {
@Override
public void run() {
//TODO:SM It would be good to optimise this
Copy link
Contributor

Choose a reason for hiding this comment

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

indentation

Async.run(new Runnable() {
@Override
public void run() {
//TODO:SM It would be good to optimise this
Copy link
Contributor

Choose a reason for hiding this comment

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

remove todo

if (!storedFiles.isEmpty()) {
SessionTrackingPayload payload = new SessionTrackingPayload(storedFiles, client.appData);

//TODO:SM Reduce duplication here and above
Copy link
Contributor

Choose a reason for hiding this comment

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

remove todo

@kattrali kattrali merged commit b24cb15 into master Jan 26, 2018
@fractalwrench fractalwrench deleted the android-fixes branch March 23, 2018 13:56
lemnik pushed a commit that referenced this pull request Jun 2, 2021
Rename properties on bugsnag extension that control request autoUpload
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.

4 participants