Sentry `handled:no` doesn't translate to `crashed sessions` in all cases

[bruno-garcia]

This is a long standing issue where Sentry's handled:true/false doesn't map correct to multiple cases.
For example, all C# unhandled errors on Unity don't crash the app. But Crash Free Rate are affected by those, mixed with actual crashes captured by the native layer.

In addition, users get confused when searching in Sentry for errors that caused the app to crash.
They see the unhandled label and fire icon. But those unhandled errors did not actual crashes.

Several SDKs cases like this, including Java, JavaScript, .NET, Unity, Dart and Flutter.

Some prior art:

• Introduce additional types of exceptions next to mechanism.handled exceptions rfcs#10
• Fix handled data and differentiate between unhandled errors and crashes sentry-javascript#6073
• Errors that don't crash the app shouldn't be logged as fatal sentry-dart#1624
• Unhandled exceptions cause sessions to be marked as crashed sentry-unity#1721
• Ability to filter by "user-perceived" unhandled exceptions/fatal errors generated by the Kotlin SDK sentry-java#3425
• RuntimeMarshalManagedException is handled:no but didn't crash the app sentry-dotnet#4261

[getsantry]

Routing to @getsentry/product-owners-releases for triage ⏲️

[buenaflor]

+1 for Flutter

Flutter by default does not crash even for unhandled errors so the crash-free rate is also wrong and a few observant users already brought this up in the Dart repo.

[bruno-garcia]

An update here, @ryan953 has put up some changes in Relay and Sentry to introduce a new status on sessions.

See:

• feat(session): Add unhandled session status type relay#4939

@bitsandfoxes started with .NET and Unity as a first SDK implementing this