-
-
Notifications
You must be signed in to change notification settings - Fork 226
feat: Cache Unhandled session instead of sending it immediately
#4653
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
Conversation
…entry/sentry-dotnet into feat/session-type-unhandled
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## version6 #4653 +/- ##
===========================================
Coverage ? 73.23%
===========================================
Files ? 480
Lines ? 17399
Branches ? 3436
===========================================
Hits ? 12743
Misses ? 3806
Partials ? 850 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…sentry/sentry-dotnet into feat/cache-unhandled-session
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
jamescrosswell
left a comment
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.
Looks good. I'd just use the new InterlockedBoolean shim that we have instead of an int for the thread safe bool.
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
…sentry/sentry-dotnet into feat/cache-unhandled-session
Resolves #4632
Followup on #4633
Problem
Sessions that end in
Unhandledcan later on still crash. Updating a session with an end status is a terminal operation, see getsentry/sentry-docs#15086 and once updated, sessions must not receive further updates. We need to make sure the SDK finishes a session only when it is confident, that a session is actually finished.Proposal
Instead of updating (and ending) a session with
SessionEndStatus.Unhandledright away we persist the state to disk. We can make use of the fact that there is a separation betweenPersistedSessionUpdateandSessionUpdate.PersistedSessionUpdateis used locally only, the SDK does not send this to Sentry and we can add a flagPendingUnhandledto itSessionUpdateis the actual update the SDK sends to SentryThe flow is as follows:
Unhandledand the update is persisted to diskCrashed, overwriting the pending unhandled stateExitedwithUnhandled.TODO
Currently, the SDK relies on restarts of the application to send the
SessionEndStatus. Ideally, we would also hook into some shutdown mechanism, or at the very least, closing the SDK should also end any active sessions.