-
Notifications
You must be signed in to change notification settings - Fork 511
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
Fix threading by carrying forward span reference in use_scope
#3851
Fix threading by carrying forward span reference in use_scope
#3851
Conversation
`use_scope` Since the otel context span reference is the source of truth for the current active span, we need to explicitly pass the span reference on the scope through when we use `use_scope` since we are changing context variables in the other thread. Also, * fixes some typing in the original scope * adds more types to the `contextvars_context` manager
use_scope
❌ 308 Tests Failed:
View the full list of 3 ❄️ flaky tests
To view more test analytics, go to the Test Analytics Dashboard |
@@ -99,7 +86,8 @@ def _run_old_run_func(): | |||
with sentry_sdk.use_scope(current_scope_to_use): | |||
return _run_old_run_func() | |||
else: | |||
return _run_old_run_func() | |||
with sentry_sdk.isolation_scope(): |
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 think the old logic here was actually wrong but kinda worked because of some fallback code in the scope implementation.
Semantically, if we don't explicitly propagate the scopes, we should ALWAYS have created a new isolation scope for the new thread.
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.
makes sense to me
92f5f0a
into
neel/potel/move-scope-init
* Move scope context init outside integration * Fix ThreadingIntegration by carrying forward span reference in (#3851) `use_scope` Since the otel context span reference is the source of truth for the current active span, we need to explicitly pass the span reference on the scope through when we use `use_scope` since we are changing context variables in the other thread. Also, * fixes some typing in the original scope * adds more types to the `contextvars_context` manager
Since the otel context span reference is the source of truth for the current active span, we need to explicitly pass the span reference on the scope through when we use
use_scope
since we are changing context variables in the other thread.Also,
propagate_hub
completelycontextvars_context
manager