getsentry
Fix stitchAsyncCode
Description
StichAsyncCode was added with https://github.com/getsentry/sentry-cocoa/pull/998, but on some devices, the stacktraces were incomplete; see comments in #998.
We should fix these problems and ideally turn on stichAsyncCode by default. Be aware that this would have an impact on grouping.
Relevant/related info:
It in turn calls setAsyncCallStackDepth which will "stitch" the stack whenever an async call is done (you can see how in v8/src/inspector/v8-debugger.cc in the chromium repo).
V8: https://stackoverflow.com/questions/68375903/how-does-v8-reconstruct-async-stacktraces-with-requestanimationframe
IntelliJ 2017.1 included a feature called Capture Points. This feature lets us stitch together stack frames so that the order of functions in the stack trace respects the order in which they were called.
https://finagle.github.io/blog/2017/11/02/async-stack-traces/
Stacktrace recovery tries to stitch asynchronous exception stacktrace with a stacktrace of the receiver by copying it, providing not only information where an exception was thrown, but also where it was asynchronously rethrown or caught.
https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/topics/debugging.md#stacktrace-recovery
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
We decided internally to go forward with https://github.com/getsentry/sentry-cocoa/issues/1919 instead to improve stacktraces for Swift concurrency only. Although it would be great to make async stacktrace work also for dispatch queues, we don't think it's worth adding a manual solution as the fishhook, which also adds some risks to mess things up. We can always revisit this decision.
Participants: @armcknight, @brustolin, @kahest, @philipphofmann