Remove DefaultSpan from public API. by anuraaga · Pull Request #1791 · open-telemetry/opentelemetry-java

anuraaga · 2020-10-13T08:05:25Z

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 · 2020-10-13T08:11:47Z

Codecov Report

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

@@             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.

anuraaga · 2020-10-13T08:52:19Z

api/src/main/java/io/opentelemetry/trace/Span.java

+   * 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) {


@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.

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?

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.

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.

jkwatson · 2020-10-13T16:58:58Z

api/src/main/java/io/opentelemetry/trace/propagation/HttpTraceContext.java

  }

-  private static <C> SpanContext extractImpl(C carrier, Getter<C> getter) {
+  private static <C> Span extractImpl(C carrier, Getter<C> getter) {


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

jkwatson · 2020-10-13T17:50:25Z

...opagators/src/main/java/io/opentelemetry/extensions/trace/propagation/AwsXRayPropagator.java


-    SpanContext spanContext = getSpanContextFromHeader(carrier, getter);
-    if (!spanContext.isValid()) {
+    Span span = extractSpan(carrier, getter);


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.

jkwatson · 2020-10-13T17:56:34Z

...java/io/opentelemetry/extensions/trace/propagation/B3PropagatorExtractorMultipleHeaders.java

  }

-  private static <C> SpanContext getSpanContextFromMultipleHeaders(
+  private static <C> Span extractFromMultipleHeaders(


ditto on reducing scope for this PR

anuraaga · 2020-10-14T02:24:49Z

@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

… into remove-default-span

anuraaga · 2020-10-14T02:31:56Z

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

jkwatson · 2020-10-14T15:01:14Z

api/src/main/java/io/opentelemetry/trace/DefaultTracer.java

-      return spanContext != null && !SpanContext.getInvalid().equals(spanContext)
-          ? new DefaultSpan(spanContext)
-          : DefaultSpan.getInvalid();
+      return Span.getPropagated(spanContext);


this is a nice cleanup. much tighter and clearer.

jkwatson

Thanks! This is a good improvement.

bogdandrutu

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.

bogdandrutu · 2020-10-14T17:23:11Z

api/src/main/java/io/opentelemetry/trace/Span.java

+   * 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) {


s/getPropagated/toPropagated?

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

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

bogdandrutu · 2020-10-14T17:24:08Z

api/src/main/java/io/opentelemetry/trace/Span.java

+  default boolean isValid() {
+    return getContext().isValid();
+  }


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

Sure makes sense

… into remove-default-span

anuraaga requested review from arminru, bogdandrutu, carlosalberto, jkwatson, pavolloffay, thisthat and tylerbenson as code owners October 13, 2020 08:05

This was referenced Oct 13, 2020

Merge SpanContext into Span and make DefaultSpan private #1712

Closed

Move isRemote from SpanContext to Span open-telemetry/opentelemetry-specification#1086

Closed

anuraaga commented Oct 13, 2020

View reviewed changes

jkwatson reviewed Oct 13, 2020

View reviewed changes

Cleanup

dae27aa

Merge branch 'master' of github.com:open-telemetry/opentelemetry-java…

59e676f

… into remove-default-span

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

Fix comment

0ceec41

jkwatson reviewed Oct 14, 2020

View reviewed changes

jkwatson approved these changes Oct 14, 2020

View reviewed changes

bogdandrutu requested changes Oct 14, 2020

View reviewed changes

Anuraag Agrawal added 2 commits October 15, 2020 08:25

Merge branch 'master' of github.com:open-telemetry/opentelemetry-java…

0b75200

… into remove-default-span

isValid not valid

2e6c3d9

bogdandrutu approved these changes Oct 15, 2020

View reviewed changes

anuraaga merged commit 2d0f91b into open-telemetry:master Oct 15, 2020

Conversation

anuraaga commented Oct 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Oct 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anuraaga Oct 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anuraaga commented Oct 14, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anuraaga commented Oct 14, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkwatson left a comment

Choose a reason for hiding this comment

Uh oh!

bogdandrutu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

anuraaga commented Oct 13, 2020 •

edited

Loading

codecov bot commented Oct 13, 2020 •

edited

Loading

anuraaga Oct 13, 2020 •

edited

Loading

anuraaga commented Oct 14, 2020 •

edited

Loading