-
Notifications
You must be signed in to change notification settings - Fork 504
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
Fixes Open Telemetry propagation for NonRecordingSpan
#1995
Conversation
This pull request 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 "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
@@ -18,6 +19,7 @@ | |||
from sentry_sdk.tracing_utils import Baggage | |||
|
|||
|
|||
|
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.
This extra blank line is making the linter fail.
I have activated |
We're experiencing this issue also. The |
Thanks a lot @nathanielobrown for investigating and for the PR! This definitely needs fixing, and based on #2187 it seems there are more places where we're still accessing As for the tests, it'd make sense to use the actual otel objects/interfaces -- happy for any PRs to improve this! |
I was getting an error
AttributeError: 'NonRecordingSpan' object has no attribute 'context'
which I think might be due to my use ofTracerProvider(sampler=TraceIdRatioBased(0.1))
, but I'm not sure exactly (I'm an otel noob).I haven't exhaustively researched the situation here, but it seems like the way the context was fetched from a span was wrong, as there is a clear getter
get_span_context
that would seems like the more "public" interface than the.context
attribute. As supporting evidence, the abstract base classSpan
hasget_span_context
but nocontext
defined.A small piece of feedback: looking at the tests for
opentelemetry
, in general it seems like they test mock objects rather than than actual objects from the opentelemetry library. Is there a reason for this? Using the underlying objects (span implementations and the like) feels like it would help prevent bugs like this one. At least using the ABC/API interfaces to generate some stubs so we know what we are testing conforms to the interface. Just a thought - I want to help make sure the opentelemetry integration is a success!Looking forward to hearing your thoughts.