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
Ability to filter by "user-perceived" unhandled exceptions/fatal errors generated by the Kotlin SDK #3425
Comments
Assigning to @getsentry/support for routing ⏲️ |
Routing to @getsentry/product-owners-issues for triage ⏲️ |
I want to provide more context on this, as I was wrong when I initially suggested that it was the coroutines exception handler was the primary cause of this observability hole. I had more time to do debugging this week and fully identify the cause of the crash. Here's the scenario: Let's say we have What is actually happening, is that because no local coroutine exception handler exists, the global coroutines exception handler re-throws the exception, and crashes This leads me to the question: Would it be possible to have two crash free rates? One which calculates the number of sessions that experienced a crash and a second one (the same as the current crash free rate) that calculates the number of sessions that ended with a crash. This would allow Sentry to provide the more nuanced context that the Play Store console shows. |
I believe that to get this working in Issues we must first get it as a tag from the SDK, so I'm transferring this issue. |
Problem Statement
Due to the behavior of coroutines exception handling, a failure to catch the exception can sometimes result in a crash, if the request was made from certain contexts, and can be swallowed when made from others.
In both of these cases, Sentry labels the error as
level:fatal
withexception.handled:false
. However, this creates the possibility for a spike in "crashes" that do not actually crash the app for the user.We recently encountered this issue with a
android_getaddrinfo
exception, where a user was trying to make a network connection while in airplane mode. What we saw is a huge spike in errors in Sentry, but when we went to Google Play, we were able to filter by user-perceived errors and see that the actual count of crashes for this issue was very very low.It appears that Sentry's "Crash free user rate" takes into consideration fatal errors that are "user perceived" vs. not (the spike in errors did not impact our crash free user rate).
Solution Brainstorm
We'd love to be able to query by
user_perceived:true
in Discover, Dashboards, and Alerts (for error data sources) so that we can differentiate between user-perceived vs non-main thread crashes ourselves.when specifying
user_perceived:true
, I would expect to only see crashes that resulted in the Android app closing, and contribute to the crash-free user rate shown by Sentry.when specifying
user_perceived:false level:fatal
, I would expect to only see errors that are swallowed up by the parent coroutine and do not actually crash the app for the user.Product Area
Issues
The text was updated successfully, but these errors were encountered: