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
The first time we call sentry-related functions in a thread, it attaches to whichever Span the main thread is currently attached to.
This causes very wrong sub-spanning (which I just spend 6 hours investigating).
Attaching to sentry client, DSN, parameters..., etc seems correct, but span definitely not.
I feel like maybe the Scope should be a property that's not inherited from whichever scope the main thread happens to be in at that moment, because if there is a sub-thread it's very possible that the main thread is doing unrelated work at that moment, and that unrelated work may very well involve its own spans and data, so it seems that it's not correct to attach to those.
Ok so my understanding is that there's no way to prevent the Hub to attach to the current scope of the main thread.
It looks like the "main Hub" shouldn't really be attached to any thread, and even the main thread should have its own Hub.
That would fix this issue.
The first time we call sentry-related functions in a thread, it attaches to whichever Span the main thread is currently attached to.
This causes very wrong sub-spanning (which I just spend 6 hours investigating).
Attaching to sentry client, DSN, parameters..., etc seems correct, but span definitely not.
I feel like maybe the Scope should be a property that's not inherited from whichever scope the main thread happens to be in at that moment, because if there is a sub-thread it's very possible that the main thread is doing unrelated work at that moment, and that unrelated work may very well involve its own spans and data, so it seems that it's not correct to attach to those.
Related issues: #507
Related writeup: https://swatinem.de/blog/log-contexts/
The text was updated successfully, but these errors were encountered: