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.

Sign up for GitHub

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

Jump to bottom

Android P FileStore flush fix #319

Merged
merged 2 commits into from
May 30, 2018
Merged

Android P FileStore flush fix #319

merged 2 commits into from
May 30, 2018

Conversation

fractalwrench
Copy link
Contributor

@fractalwrench fractalwrench commented May 24, 2018 •
edited by kattrali
Loading

Goal

Some unhandled error reports aren't being sent immediately on Android P and in situations with no connectivity.

Internally FileStore retains a Collection of files which have previously been found for a request, to prevent duplicate reports being sent. This puts the onus on the calling code to cancel or delete the files once the request has been completed.

This changeset ensures that these files are only requested once when calling flushOnLaunch, then cancels all files after delivery has taken place (successfully or not), which resets the FileStore state.

After this, flushAsync is then called, which will flush any remaining reports that have not yet been delivered.

Changeset

Changed

FileStore (see above description)

Tests

Manual test on Android P simulator of unhandled crashes. Mazerunner scenario that fails prior to the applied fix.

Discussion

Alternative Approaches

The delivery/flushing code is fairly complex, it may be worth rethinking our implementation at some future point.

Linked issues

#318

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 requested a review from a team May 24, 2018 10:02
@coveralls
Copy link

coveralls commented May 24, 2018 •
edited
Loading

Coverage Status

Coverage increased (+0.02%) to 79.026% when pulling eac2708 on android-p-flush-fix into 7184806 on master.

kattrali
kattrali reviewed May 24, 2018
View reviewed changes
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.

The fix makes sense. I have one concern about the test to ensure that the setup doesn't diverge from the what happens when real reports are captured.

mazerunner/src/main/java/com/bugsnag/android/mazerunner/scenarios/StartupCrashFlushScenario.kt Outdated
val client = Bugsnag.getClient()
val defaultLaunchThresholdMs = config.launchCrashThresholdMs
config.launchCrashThresholdMs = Long.MAX_VALUE
writeErrorToStore(client)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why force a manual write to the file cache rather than causing an error to happen via notify/crashing? It may mean requiring additional steps to prepare the scenario but seems closer to what would happen in the real world.

@fractalwrench
Copy link
Contributor Author

I've updated the mazerunner scenario to throw exceptions rather than writing errors to the store.

I've also made a slight adjustment to the ErrorStore logic so that if config.launchCrashThresholdMs == 0, all reports will be flushed async, as launch crash delivery behaviour is disabled. This addresses an internal ticket.

@fractalwrench fractalwrench requested a review from a team May 25, 2018 09:27
snmaynard
snmaynard previously requested changes May 25, 2018
View reviewed changes
mazerunner/src/main/java/com/bugsnag/android/mazerunner/scenarios/StartupCrashFlushScenario.kt Outdated
disableAllDelivery()

if ("StartupCrash" == eventMetaData) {
config.launchCrashThresholdMs = Long.MAX_VALUE
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this needs some rethinking. I think you dont want to set config.launchCrashThresholdMs in here. Also both of these crashes will count as launch crashes on subsequent boots.

@fractalwrench
Copy link
Contributor Author

Updated the docs to make it a bit clearer what this scenario is doing, and also updated mazerunner to disable delivery before Bugsnag is initialised.

@kattrali
Copy link
Contributor

Reworked the test to better illustrate the user scenario here, and introduced a delay to separate the launch crash from a regular one.

@fractalwrench @kattrali
test: Ensure both a startup crash + regular crash are delivered
22b3dba
@fractalwrench @kattrali
fix: Cancel crash reports after flushing startup crashes
eac2708 
Internally FileStore retains a Collection of files which have previously been found for a request,
to prevent duplicate reports being sent. This puts the onus on the calling code to cancel or delete
the files once the request has been completed. This change ensures that the storedFiles are only
requested once, then filtered for crashes on launch, and then all files are cancelled after a
reasonable amount of time has passed regardless of delivery, which reset the internal FileStore
state. flushAsync is then called which will flush any remaining reports that have not yet been
delivered
kattrali
kattrali approved these changes May 30, 2018
View reviewed changes
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.

works well 👍

@kattrali kattrali dismissed snmaynard’s stale review May 30, 2018 19:37

changeset updated to address testing concerns

@kattrali kattrali merged commit cfa9250 into master May 30, 2018
@kattrali kattrali deleted the android-p-flush-fix branch May 30, 2018 22:18
rich-bugsnag pushed a commit that referenced this pull request Sep 3, 2021
@twometresteve
Merge pull request #319 from bugsnag/tms/windows-build-poc
a46f49d 
Build Windows test fixtures
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kattrali kattrali kattrali approved these changes

@snmaynard snmaynard snmaynard left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@fractalwrench @coveralls @kattrali @snmaynard