Skip to content
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

Remove DefaultSpan from public API. #1791

Merged
merged 5 commits into from
Oct 15, 2020

Conversation

anuraaga
Copy link
Contributor

@anuraaga anuraaga commented Oct 13, 2020

We use DefaultSpan, a no-op wrapper of a spancontext, for three use cases

  • propagated span
  • unsampled span
  • disabling implicit tracing in a scope

So it actually didn't make sense to use the propagated span terminology to replace it. I used a wrapAsNoop factory instead since that's literally what we're doing. To give the propagated term some love, I renamed the relevant SpanContext factory to use the word. Realized I was confusing propagated span with remote span but they are different.

Would be much easier to reason about without the SpanContext I guess 😋

Fixes #1704

@codecov
Copy link

codecov bot commented Oct 13, 2020

Codecov Report

Merging #1791 into master will increase coverage by 0.07%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1791      +/-   ##
============================================
+ Coverage     84.60%   84.67%   +0.07%     
- Complexity     1429     1431       +2     
============================================
  Files           177      177              
  Lines          5554     5554              
  Branches        579      578       -1     
============================================
+ Hits           4699     4703       +4     
+ Misses          648      645       -3     
+ Partials        207      206       -1     
Impacted Files Coverage Δ Complexity Δ
...ain/java/io/opentelemetry/trace/DefaultTracer.java 100.00% <100.00%> (+2.85%) 5.00 <0.00> (ø)
...in/java/io/opentelemetry/trace/PropagatedSpan.java 78.26% <100.00%> (ø) 16.00 <2.00> (?)
api/src/main/java/io/opentelemetry/trace/Span.java 100.00% <100.00%> (ø) 5.00 <4.00> (+4.00)
...va/io/opentelemetry/trace/TracingContextUtils.java 100.00% <100.00%> (ø) 7.00 <0.00> (ø)
...ntelemetry/trace/propagation/HttpTraceContext.java 96.46% <100.00%> (ø) 32.00 <0.00> (ø)
...xtensions/trace/propagation/AwsXRayPropagator.java 87.20% <100.00%> (ø) 26.00 <0.00> (ø)
...pagation/B3PropagatorExtractorMultipleHeaders.java 100.00% <100.00%> (ø) 8.00 <0.00> (ø)
...propagation/B3PropagatorExtractorSingleHeader.java 96.15% <100.00%> (ø) 10.00 <0.00> (ø)
...extensions/trace/propagation/JaegerPropagator.java 87.50% <100.00%> (ø) 26.00 <0.00> (ø)
...tensions/trace/propagation/OtTracerPropagator.java 82.75% <100.00%> (ø) 10.00 <0.00> (ø)
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0ceff17...2e6c3d9. Read the comment docs.

* functionality. It will not be exported and all operations are no-op, but it can be used to
* propagate the {@link SpanContext} downstream.
*/
static Span wrapWithNoop(SpanContext spanContext) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Oberon00 Based on the conversation in open-telemetry/opentelemetry-specification#1086 this should be something like wrapForPropagation, we're wrapping this SpanContext into a PropagatedSpan. This seems like odd naming to me though, as there is nothing about propagation happening here really, doubly-so because propagation is still more commonly used for remote propagation than in-process propagation I think. That's not great here since we don't do remote propagation of the invalid span.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as there is nothing about propagation happening here really

If one considers making a span a local parent "propagation" (which I think one should), then it makes sense. Because what other uses would this returned object have?

Copy link
Contributor Author

@anuraaga anuraaga Oct 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because what other uses would this returned object have?

I dunno maybe someone will have something creative :) While it's indirect usage of this API, one case where it will be used is when extracting the SpanContext from a link - the result of this method will be taken out of the Context, the link will be made, and the result will be dropped without ever being propagated. So this is where the disconnect with the naming comes from - since it's completely up to the caller on whether it's propagated or not, so I find it pretty confusing. There's the other point where there's no such thing as a non-propagated span - all spans can be propagated, so why do we have the propagated span called out in particular? I'm sure someone is going to call Span.getPropagated(tracer.startSpan().getContext()) assuming that's how you're supposed to propagate your span ;) Span.getNoop(tracer.startSpan().getContext()), Span.getNonRecording(...) seems more obviously wrong because it better reflects what's actually happening.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love this name, but I 100% agree with the sentiment. Making it super clear what the capabilities (and lack thereof) will be of the returned Span seems like a very important signal to the user.

}

private static <C> SpanContext extractImpl(C carrier, Getter<C> getter) {
private static <C> Span extractImpl(C carrier, Getter<C> getter) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change seems a bit orthogonal to the PR. Does it need to be included?

@@ -123,18 +122,18 @@ public static AwsXRayPropagator getInstance() {
Objects.requireNonNull(carrier, "carrier");
Objects.requireNonNull(getter, "getter");

SpanContext spanContext = getSpanContextFromHeader(carrier, getter);
if (!spanContext.isValid()) {
Span span = extractSpan(carrier, getter);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to separate out this changes into a follow-on PR, just to keep this one a little more tight in its scope.

}

private static <C> SpanContext getSpanContextFromMultipleHeaders(
private static <C> Span extractFromMultipleHeaders(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto on reducing scope for this PR

@anuraaga
Copy link
Contributor Author

anuraaga commented Oct 14, 2020

@jkwatson Good call - I also went ahead and named the method getPropagated to stick with the spec for now. Hoping will be able to rename it later, it's just 10secs in IntelliJ to rename :) Edit: Well I will after resolving merge conflict

@anuraaga anuraaga force-pushed the remove-default-span branch from 9520587 to 59e676f Compare October 14, 2020 02:28
@anuraaga
Copy link
Contributor Author

Had a scary unexpected force push but branch seems to be ok, phew

return spanContext != null && !SpanContext.getInvalid().equals(spanContext)
? new DefaultSpan(spanContext)
: DefaultSpan.getInvalid();
return Span.getPropagated(spanContext);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a nice cleanup. much tighter and clearer.

Copy link
Contributor

@jkwatson jkwatson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This is a good improvement.

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the overall change of "PropagationSpan" but I don't like that we add other changes to the API like the "isValid" in the same PR. That change is independent and can be added in a separate PR.

* functionality. It will not be exported and all tracing operations are no-op, but it can be used
* to propagate a valid {@link SpanContext} downstream.
*/
static Span getPropagated(SpanContext spanContext) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/getPropagated/toPropagated?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be called Span.wrap(SpanContext). Then we are also safe against renamings of propagated/noop/etc

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we are safe against behavior change, this needs to always propagate the SC. But +1 for the name

Comment on lines 332 to 334
default boolean isValid() {
return getContext().isValid();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change is unrelated with the PR description and purpose, consider to not add "secondary" changes to a PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure makes sense

@anuraaga anuraaga merged commit 2d0f91b into open-telemetry:master Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update DefaultSpan to match the new spec
4 participants