SDK Crash Detection: Enable Dart/Flutter
Enable the SDK crash detection for the sentry-dart SDK.
### Tasks
- [ ] https://github.com/getsentry/sentry-dart/pull/2050
- [ ] https://github.com/getsentry/sentry/pull/71233
- [ ] https://github.com/getsentry/sentry/pull/71318
- [ ] https://github.com/getsentry/sentry-options-automator/pull/1464
- [ ] https://github.com/getsentry/sentry-options-automator/pull/1465
@buenaflor, I need your input, please. If you need a refresher on what SDK crash detection is, read this.
I plan to enable the SDK crash detection for the Dart SDK. To do this, I need to create a configuration similar to what we already have for the Java SDK.
https://github.com/getsentry/sentry/blob/3e90887a3632585b048f607668e20927321a39a0/src/sentry/utils/sdk_crashes/sdk_crash_detection_config.py#L154-L202
This is how the configuration would roughly look:
dart_config = SDKCrashDetectionConfig(
# ...
sdk_names=["sentry.dart", "sentry.dart.flutter"],
# 7.9.0 was released in July 2023, see https://github.com/getsentry/sentry-dart/releases/tag/7.9.0
min_sdk_version="7.9.0",
system_library_path_patterns={
r"third_party/dart/sdk/**", # Dart
r"/opt/flutter/packages/flutter/**", # Flutter
},
sdk_frame_config=SDKFrameConfig(
function_patterns=set(),
path_patterns={
r"**/sentry-**",
},
path_replacer=KeepAfterPatternMatchPathReplacer(
patterns={
r"\/sentry-.*",
},
fallback_path="sentry",
),
),
sdk_crash_ignore_functions_matchers=set(),
)
@buenaflor, please answer the following questions:
- Does the Dart SDK have more SDK names? If yes, which ones?
- Which
system_library_path_patternsshould I add? This is for keeping system library or system binary frames in the stacktrace for SDK crashes? - If I'm not mistaken, all Sentry Dart SDK frames have
sentry-in theirabs_pathfollowed by the version number of the SDK? Is there a better reliable way to detect Sentry Dart SDK frames? - Regarding
sdk_crash_ignore_functions_matchers: For Cocoa we have a test function causing a crash we want to ignore. Does the Sentry Dart SDK have something similar?
- afaik the names include:
sentry.dart,sentry.dart.flutter,sentry.dart.browser - Judging by some of the abs_paths:
package:flutter/src/gestures/tap.dart,dart:ui/platform_dispatcher.dart, something liker"flutter/**" andr"dart:**", but I'm not too sure about the syntax. As for web errors it seems a bit more complicated since there is no obvious system library path, e.g this web stacktrace, for examplehttp://localhost:53744/binding.dart - The abs path usually looks like
package:sentry**orpackage:sentry_flutter**I'm wondering though how we can detect sdk frames at all since we remove them: https://github.com/getsentry/sentry-dart/blob/6575860857eb9784ce13785f3a2eeade01013808/dart/lib/src/sentry_stack_trace_factory.dart#L44 - No we don't
I'm wondering though how we can detect sdk frames at all since we remove them: https://github.com/getsentry/sentry-dart/blob/6575860857eb9784ce13785f3a2eeade01013808/dart/lib/src/sentry_stack_trace_factory.dart#L44
@buenaflor, upsi, that's a blocker. Can we start sending them? On Java, we send SDK frames in case of a crash (https://github.com/getsentry/sentry-java/pull/3021), but it's better to do this in the next major because it can affect grouping. Otherwise, the SDK crash detection won't work.
Hmm is it still feasible to do it in the current major? we've released v8 but it's still pretty new. otherwise we can add this to v9 but tbh I'm not sure when the next major for dart would be released
@buenaflor, strictly speaking, no, we shouldn't do this without a major, but as these frames aren't inApp in most cases they shouldn't impact grouping. @kahest what do you think?
I'm wondering why we removed them in the first place. In general I'm ok with doing this in 8.2.0 if we are sufficiently confident that it doesn't affect grouping, especially since v8 is still very new
Just traced back the change at it has been there since 2020. I'll check how it affects grouping
inApp in most cases they shouldn't impact grouping
This seems to be the case here as well, I tried it out and it still is grouped with the same error without the sentry frame. So I think we're good to go in removing it without a major
Example: https://sentry-sdks.sentry.io/issues/4722238716/events/d70d73150b2a401e9b56755f968cc1de/?project=5428562&query=is%3Aunresolved+issue.priority%3A%5Bhigh%2C+medium%5D&referrer=next-event&statsPeriod=1h&stream_index=0
Sentry frames are now included in dart stacktraces as of 8.2.0
I'm going to use the same rules for system frames that we use for grouping https://github.com/getsentry/sentry/blob/c4c4c9f4e8de9662c6fcb6ea123b8ab4cd34d133/src/sentry/grouping/enhancer/enhancement-configs/newstyle%402023-01-11.txt#L83-L85
We can't make it work for Flutter Browser because the stacktrace paths don't include enough information to reliably detect where frames come from, but I think that's acceptable.
{
"function": "<fn>",
"filename": "main.dart",
"abs_path": "http://localhost:53617/main.dart",
},
{
"function": "setTag",
"filename": "sentry_tracer.dart",
"abs_path": "http://localhost:53617/sentry_tracer.dart",
},
{
"function": "_get]",
"filename": "js_array.dart",
"abs_path": "http://localhost:53617/js_array.dart",
},
{
"function": "throw_",
"filename": "errors.dart",
"abs_path": "http://localhost:53617/errors.dart",
}
We're sampling at 100% now https://github.com/getsentry/sentry-options-automator/pull/1518. We can close this.