-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(core): fatal events should set session as crashed
#15072
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lforst
approved these changes
Jan 20, 2025
Collaborator
Author
|
I'm also going to backport this to v8! |
Contributor
size-limit report 📦
|
AbhiPrasad
pushed a commit
that referenced
this pull request
Jan 20, 2025
3 tasks
Lms24
added a commit
that referenced
this pull request
Nov 10, 2025
…atus from event with exceptions (#18137) This PR fixes an oversight in our session update logic when we update the SDK's session status while processing an error event. Previously, we'd always set `status: 'crashed'` as soon as the top-level `event.level` field was set to `'fatal'` (added in #15072). However, this disregarded the case where the level was initially `'fatal'` but later on the SDK or users decided to set the `event.exceptions.values[i].mechanism.handled` field to `true`. Simplest reproduction: ``` Sentry.captureException(new Error('test'), { captureContext: { level: 'fatal' } }); ``` This PR changes the update logic to only look at the event mechanisms if the event contained exceptions. I _think_ this is still compatible with #15072 because the PR suggests we only care about `event.level === 'fatal'` if no exceptions are on the event. But I'd appreciate a second pair of eyes on this (cc @timfish).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In the Electron SDK, we have to manually set sessions as crashed when native crashes are encountered:
https://github.com/getsentry/sentry-electron/blob/dabd6daf0c19c2a6f224d1e721eb5d58c3cf61ac/src/main/integrations/sentry-minidump/index.ts#L175
This has the downside that if you return
nullinbeforeSend, the event still impacts the release health crash rate.I found that this was required because
_updateSessionFromEventin@sentry/coredoes not consider the Electron native events as a crash or an error because there are no exceptions in the event.This PR ensures that any event with a
fatallevel is considered a crash.