-
Notifications
You must be signed in to change notification settings - Fork 12
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
Expose an API to override Sentry's stitchAsyncCode option #260
Conversation
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.
At the time of writing this PR, there is a getsentry/sentry-cocoa#3051 in the latest Sentry version 8.8.0, named swiftAsyncStacktraces. However, this option didn't provide the expected results in the test cases outlined in wordpress-mobile/WordPress-iOS#20912. In contrast, the stitchAsyncCode option delivered better results.
I appreciated that implementation might have been working well during testing, however, according to Sentry's own changelog
[The
stitchAsyncCode
] behavior was unpredictable and sometimes resulted in unexpected errors.
As a matter of fact, the option was removed from the library.
I'm afraid relying on this option will either result us facing the unexpected runtime behavior the Sentry team reported or put us in the difficult position of not being able to upgrade.
@@ -63,6 +63,7 @@ public class CrashLogging { | |||
|
|||
/// Attach stack traces to non-fatal errors | |||
options.attachStacktrace = true | |||
options.stitchAsyncCode = self.dataProvider.enhancedAsyncStacktraces |
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.
I like the "enhanced async stacktraces" as a name for this parameter.
Given
|
The feature being experimental is a liability, in that they might roll it back at some point forcing us to update our code. But, given that's their latest version it seems a more secure approach than using a setting they already removed. |
True, it is still an experimental and early feature.
As far as I understood, this option seems to be safe. For non-swift-async use cases, internals behaves the same way as before:
However, as, @salimbraksa mentioned, this option is not as effective now:
AFAIK, it's only designed to work for native Swift concurrency (async/await). There aren't many places in the code using it yet. Given the feature is experimental and introduced in the latest Sentry version, and is not likely to provide many insights at the moment, I say we wait for a newer Sentry version when this Swift async support is more solid. |
That sounds good to me. My initial intention was to use the experimental
Given the reduced occurrence of |
Ref p1687271187638419-slack-C05CANZ2B6F
As the PR title says, we are adding the
options.stitchAsyncCode
during the Sentry initialization. It isfalse
by default but clients can override that option.This PR is needed for:
At the time of writing this PR, there is a newer option in the latest Sentry version 8.8.0, named
swiftAsyncStacktraces
. However, this option didn't provide the expected results in the test cases outlined in wordpress-mobile/WordPress-iOS#20912. In contrast, thestitchAsyncCode
option delivered better results.CHANGELOG.md
if necessary.