-
Notifications
You must be signed in to change notification settings - Fork 251
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: Update untraced
to suppress logging "Calling finish on an ended Span" warnings
#1620
fix: Update untraced
to suppress logging "Calling finish on an ended Span" warnings
#1620
Conversation
…d Span" warnings
Can you please add a test that demonstrates the change in behaviour? I'm unsure why this change would fix the warning in the example you provided - in both cases, a non-recording API |
bf5b7b2
to
108bde4
Compare
Added tests in 108bde4 without the change, you are going to see these failures:
|
@@ -329,5 +329,28 @@ | |||
_(span.status.code).must_equal(OpenTelemetry::Trace::Status::ERROR) | |||
_(span.status.description).must_equal('Unhandled exception of type: RuntimeError') | |||
end | |||
|
|||
it 'yields a no-op span within an untraced block' do | |||
tracer_provider.sampler = Samplers::ALWAYS_ON |
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.
Do we really want untraced to bypass ALWAYS_ON?
Is they what other Language SDKs do?
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.
oh, this line is not needed for this PR, it seems I copy-pasted too much. I'm going to remove it.
Do we really want untraced to bypass ALWAYS_ON?
I think this is a separate topic and unrelated to this PR...
Thank you! This is clearer to me now. The existing code in So in this case, we want to return a distinct non-recording |
@@ -138,7 +138,7 @@ def internal_start_span(name, kind, attributes, links, start_timestamp, parent_c | |||
trace_id ||= @id_generator.generate_trace_id | |||
result = @sampler.should_sample?(trace_id: trace_id, parent_context: parent_context, links: links, name: name, kind: kind, attributes: attributes) | |||
span_id = @id_generator.generate_span_id | |||
if result.recording? && !@stopped | |||
if !OpenTelemetry::Common::Utilities.untraced?(parent_context) && result.recording? && !@stopped |
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.
IMO we should return a non-recording span without calling @sampler.should_sample
if untraced?(parent_context)
.
Rationale:
- We should not create a non-recording span using the tracestate from a sampler whose result we're overriding.
- We should re-use the span ID from the parent span (if there is one) to avoid breaking the trace (in case we propagate the trace context with an outbound request and the server makes it own sampling decision).
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.
like this? 5f9b4a2
|
||
if OpenTelemetry::Common::Utilities.untraced?(parent_context) | ||
span_id = parent_span_id || @id_generator.generate_span_id | ||
return OpenTelemetry::Trace.non_recording_span(OpenTelemetry::Trace::SpanContext.new(trace_id: trace_id, span_id: span_id)) | ||
end |
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 looks correct to me.
For anyone who ends up here (as I did) while tracking down why we're seeing |
As @stevenharman said this change is now available in |
I believe the root cause is the same with this issue
Background
We are observing
Calling set_attribute on an ended Span
andCalling finish on an ended Span
warnings whenOpenTelemetry::Common::Utilities.untraced
is used, after upgrading opentelemetry-sdk to 1.2.1.You can reproduce it by adding the following code to a Rails controller:
This PR seems to be the cause:
Changes summary
Moved the
untraced?
check fromTrace::Tracer#start_span
toTrace::TracerProvider#internal_start_span