docs(sessions): Add docs for unhandled session status#15086
docs(sessions): Add docs for unhandled session status#15086
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Bundle ReportChanges will decrease total bundle size by 15 bytes (-0.0%) ⬇️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: sentry-docs-client-array-pushAssets Changed:
view changes for bundle: sentry-docs-server-cjsAssets Changed:
|
| - a complete crash of the application occurred (crash to desktop, termination) | ||
| - a user feedback dialog is surfaced to the user. After this, the SDK must start a new session as if it fully crashed.; | ||
| - a complete crash of the application occurred (crash to desktop, termination). | ||
| - a user feedback dialog is surfaced to the user. After this, the SDK must start a new session as if it fully crashed. |
There was a problem hiding this comment.
| - a user feedback dialog is surfaced to the user. After this, the SDK must start a new session as if it fully crashed. | |
| - a crash report user feedback dialog is surfaced to the user. After this, the SDK must start a new session as if it fully crashed. |
There was a problem hiding this comment.
is this specific to sentry's dialog?
| ### Crashed, Abnormal vs Errored | ||
| ### Crashed, Unhandled, Abnormal vs Errored | ||
|
|
||
| A session is supposed to transition to `crashed` when it encountered an a full |
There was a problem hiding this comment.
| A session is supposed to transition to `crashed` when it encountered an a full | |
| A session is supposed to transition to `crashed` when it encountered a full |
There was a problem hiding this comment.
| A session is supposed to transition to `crashed` when it encountered an a full | |
| A session is supposed to transition to `crashed` when it encounters a full |
| the user encountered an error dialog. For server environments where we create sessions | ||
| for every incoming request, `crashed` is basically like status code `500` internal server error. | ||
| So if there is an unhandled error happening during the request, the session should be `crashed`. | ||
| Note that `unhandled` became supported on the server in v25.9.0, prior to that |
There was a problem hiding this comment.
| Note that `unhandled` became supported on the server in v25.9.0, prior to that | |
| Note that `unhandled` became supported on the server in v25.9.0. Prior to that, |
|
|
||
| Abnormal are sessions of which their fate is unknown. For desktop applications, for instance, it makes sense to transition a session to abnormal if it was stored | ||
| but the exit of the application was not observed but also did not crash. These are situations where the user forced the app to close via the | ||
| `abnormal` are sessions of which their fate is unknown. For desktop |
There was a problem hiding this comment.
| `abnormal` are sessions of which their fate is unknown. For desktop | |
| `abnormal` are sessions where their fate is unknown. For desktop |
| but the exit of the application was not observed but also did not crash. These are situations where the user forced the app to close via the | ||
| `abnormal` are sessions of which their fate is unknown. For desktop | ||
| applications, for instance, it makes sense to transition a session to `abnormal` | ||
| if it was stored but the exit of the application was not observed but also did |
There was a problem hiding this comment.
| if it was stored but the exit of the application was not observed but also did | |
| if it was stored but application exit was not observed but also did |
|  | ||
|
|
||
| ## Crashes | ||
| ## Crashes & Unhandled |
There was a problem hiding this comment.
| ## Crashes & Unhandled | |
| ## Crashes & Unhandled Errors |
maybe?
| ## Crashes & Unhandled | ||
|
|
||
| A _crash_ is when the application had an explicit unhandled error or hard crash. You'll typically be able to view the corresponding issue that captures this event in [sentry.io](https://sentry.io), and errors that did not cause the end of the application should not be included. To search for crash events in **Discover** or on the **Issues** page, filter by `error.unhandled:true`. | ||
| A _crash_ is when the application had a hard crash, while _unhandled_ is when an error that wasn't explicitly handled by the application. You'll typically be able to view the corresponding issue that captures this event in [sentry.io](https://sentry.io), and errors that did not cause the end of the application should not be included. To search for crash events in **Discover** or on the **Issues** page, filter by `error.unhandled:true`. |
There was a problem hiding this comment.
| A _crash_ is when the application had a hard crash, while _unhandled_ is when an error that wasn't explicitly handled by the application. You'll typically be able to view the corresponding issue that captures this event in [sentry.io](https://sentry.io), and errors that did not cause the end of the application should not be included. To search for crash events in **Discover** or on the **Issues** page, filter by `error.unhandled:true`. | |
| A _crash_ is when the application had a hard crash, while _unhandled_ is an error that wasn't explicitly handled by the application. You'll typically be able to view the corresponding issue that captured the crashed event in [sentry.io](https://sentry.io); errors that did not cause the end of the application should not be included. To search for crash events in **Discover** or on the **Issues** page, filter by `error.unhandled:true`. |
There was a problem hiding this comment.
this paragraph is a bit unclear now that unhandled was added
| A _crash_ is when the application had an explicit unhandled error or hard crash. You'll typically be able to view the corresponding issue that captures this event in [sentry.io](https://sentry.io), and errors that did not cause the end of the application should not be included. To search for crash events in **Discover** or on the **Issues** page, filter by `error.unhandled:true`. | ||
| A _crash_ is when the application had a hard crash, while _unhandled_ is when an error that wasn't explicitly handled by the application. You'll typically be able to view the corresponding issue that captures this event in [sentry.io](https://sentry.io), and errors that did not cause the end of the application should not be included. To search for crash events in **Discover** or on the **Issues** page, filter by `error.unhandled:true`. | ||
|
|
||
| Starting with v25.9.0, Sentry differentiates between crashes and unhandled errors and both are counted separately. Check your SDK release notes and update to the latest version to support _unhandled_ session status. |
There was a problem hiding this comment.
| Starting with v25.9.0, Sentry differentiates between crashes and unhandled errors and both are counted separately. Check your SDK release notes and update to the latest version to support _unhandled_ session status. | |
| Starting with v25.9.0, Sentry differentiates between crashes and unhandled errors, and both are counted separately. Check your SDK release notes and update to the latest version to support _unhandled_ session status. |
|
|
||
| One common misconception is that session data is derived from issues, and that the numbers can be cross referenced. This is not the case. | ||
|
|
||
| Session data is unconditionally sent from SDKs when the integration is enabled (it is enabled by default in most SDKs). This dataset tracks every session as it is started and ended, and includes only basic tags related to release and environment. In contrast, Issues are derived from error events, which are subject to [inbound filters](/concepts/data-management/filtering/) and [sampling](/platform-redirect/?next=/configuration/sampling/) and [quota](/pricing/quotas/) limits. |
There was a problem hiding this comment.
| Session data is unconditionally sent from SDKs when the integration is enabled (it is enabled by default in most SDKs). This dataset tracks every session as it is started and ended, and includes only basic tags related to release and environment. In contrast, Issues are derived from error events, which are subject to [inbound filters](/concepts/data-management/filtering/) and [sampling](/platform-redirect/?next=/configuration/sampling/) and [quota](/pricing/quotas/) limits. | |
| Session data is unconditionally sent from SDKs when the integration is enabled (it is enabled by default in most SDKs). This dataset tracks every session start and end, and includes only basic tags related to release and environment. In contrast, issues are derived from error events, which are subject to [inbound filters](/concepts/data-management/filtering/), [sampling](/platform-redirect/?next=/configuration/sampling/), and [quota](/pricing/quotas/) limits. |
|
|
||
| ### Unhandled | ||
|
|
||
| The application had an explicit error that was not explicitly [unhandled](#crashes--unhandled). The language or framework prevented the process from terminating. |
There was a problem hiding this comment.
should it say "handled"?
| sessions ending in `exited` will be considered for session durations. | ||
| A session is allowed to go to `exited` even if errors occurred. | ||
|
|
||
| - `unhandled`: a session should be reported as unhandled under the following cases: |
There was a problem hiding this comment.
| - `unhandled`: a session should be reported as unhandled under the following cases: | |
| - `unhandled`: a session should be reported as unhandled in the following cases: |
| It's acceptable to transition to the `crashed` state if the user encountered an | ||
| error dialog. | ||
| For server environments where we create sessions for every incoming request, | ||
| `unhandled` is basically like status code `500` internal server error. |
There was a problem hiding this comment.
| `unhandled` is basically like status code `500` internal server error. | |
| `unhandled` is basically like status code `500 Internal Server Error`. |
DESCRIBE YOUR PR
Adding docs to describe the new Session status type:
unhandled.This status is only for Session data, not Issues!
We've basically taken the existing
crashedstatus and split it into two parts:SDK Maintainers
As SDKs adopt this new status they will probably want to update pages like https://docs.sentry.io/platforms/javascript/configuration/releases/ to include a note about the new status, and the version when it was first supported.
Regardless of the SDK version, self-serve users will need server v25.9.0 to support
unhandledproperly.IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: