Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: Add onCrashedLastRun #808
feat: Add onCrashedLastRun #808
Changes from 17 commits
0961c89
416321d
bd556f4
fd0d836
eb52611
29ce980
cebee03
16ff083
c99eeab
cc4c291
1633157
dacc561
b3e49d8
80439ea
fa66553
44b4f5e
01ee8fc
8a9faea
b04e388
4950e6b
008008d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
H: I think this would work for most of the cases, but it's flakey IMO.
how do we know that the
event
callingonCrashedLastRun
is actually the one that caused the crash?I'd suggest another approach:
SentryCrash sets
fixture.crashAdapter.internalCrashedLastLaunch
so it knows the event that caused this flag to be toggled.What about caching the
eventId
as well that caused the app to crash and later, we filter by eventId? so we'll be sure that theonCrashedLastRun
is actually called with theevent
that actually crashed the App.My concern is, if the app is offline and there are multiple and distinct hard crashes, the event called
onCrashedLastRun
might not be the event that actually caused the last crash and the user feedback won't be accurate.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's very good that you think about such edge cases, but I think we can take another simpler approach.
When a crash happens, SentryCrash writes a crash-report.json to disk. The next time the app is launched, the SDK installs the
SentryCrashIntegration
, which calls theSentryCrashReportConverter
, who converts the crash-report.json to a SentryEvent. TheSentryCrashReportSink
then calls[SentrySDK captureCrashEvent:event];
. At that point, SentrySDK knows that it is an event with a crash. TheSentryHub
also has acaptureCrashEvent
, but theSentryClient
doesn't. Therefore I suggest that theSentryHub
just passes this information to theSentryClient
and incallOnCrashedLastRun
we can simplify the logic a lot.Good point I'm going to change this.