You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a server app with multiple in-flight requests, there will likely be multiple trace contexts in the app process when the blocking is detected in the ANR process. We might be able to access the offending trace context via the debugger interface if it's stored on the global scope. This is assuming the debugger respects the AsyncLocalStorage boundaries 🤔
If the main process event loop is blocked indefinitely, Sentry will not send any more envelopes so will attaching the trace context to the ANR event be of any use?
ANR events are captured and sent from the independent ANR process where we don't have the context. We can't rely on sending events from the main app process because the event loop could be blocked indefinitely.
It looks like we might be able to grab the trace context from the app process via the debugger in much the same way that we read variables in the LocalVariables integration. Rather than read the local stack variables, we can read the global variables at the time of the debugger pause.
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/node
SDK Version
7.74.0
Framework Version
No response
Link to Sentry event
No response
SDK Setup
No response
Steps to Reproduce
Reported by @ollipa as part of #9307
Expected Result
You should see a trace context on the ANR error
Actual Result
No trace context 😢
The text was updated successfully, but these errors were encountered: