-
Notifications
You must be signed in to change notification settings - Fork 849
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
Merge SpanContext into Span and make DefaultSpan private #1712
Conversation
3ad25a3
to
58d60db
Compare
Codecov Report
@@ Coverage Diff @@
## master #1712 +/- ##
============================================
- Coverage 85.48% 85.29% -0.20%
- Complexity 1378 1382 +4
============================================
Files 164 163 -1
Lines 5402 5433 +31
Branches 559 566 +7
============================================
+ Hits 4618 4634 +16
- Misses 586 595 +9
- Partials 198 204 +6
Continue to review full report at Codecov.
|
String getTraceIdAsHexString(); | ||
|
||
String getSpanIdAsHexString(); | ||
|
||
TraceState getTraceState(); | ||
|
||
byte getTraceFlags(); |
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 actually seems worse than before. Could we return a DefaultSpan here instead?
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.
Link
is strange in being over-coupled to export right now. I don't think export structures should be based on e.g., Span
so I'll look at it in #1714.
This PR is already huge. I suggest moving the "make DefaultSpan private" to a separate/follow-up PR. You could select this PR's branch as target branch and link it in the PR description. Or ensure it is separate in the commit history of this PR at least. |
@Oberon00 I found a lot of code using |
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 needs to go to the specs, because we remove an important concept from the API
Yeah but since open-telemetry/opentelemetry-specification#999 is marked after-ga it won't be acted on right? Are we stuck with the cruft because of that? I would still say we haven't really removed anything, it's just a matter of presentation within the Java code. |
private final String traceId; | ||
private final String spanId; | ||
private final byte traceFlags; | ||
private final TraceState traceState; |
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.
does it work to store a propagated Span
here instead?
@bogdandrutu can you give us some options for how we can move forward with this before GA? This looks like a really good change, especially now with Propagated Span, I also think this is a very good point from @anuraaga:
|
@anuraaga maybe go ahead and send spec PR for open-telemetry/opentelemetry-specification#999? IIRC after-ga means not required for ga, it doesn't preclude a spec PR from being accepted prior to GA, I would think especially a spec PR that doesn't require other SDKs to do any new work |
Spec is already frozen for non-editorial changes. Maybe you can get an exception for that one though? As it does not increase (required) work for SIGs. |
I added this topic to the maintainers meeting agenda for tomorrow to explore our options |
@trask (I think) it's just a one line change so doesn't hurt to make a PR indeed :) open-telemetry/opentelemetry-specification#1022 |
Does current spec prevent us from having |
@iNikem Nope that was changed in open-telemetry/opentelemetry-specification#969. So for issues of bridging, I think an interface would be fine too if this can't be accepted. But I realized the API could be made much simpler here while working on that PR :) |
If we make |
@iNikem Didn't think of that idea - seems to be an ok option if |
io.opentelemetry.trace.Span span = tracer().getCurrentSpan(); | ||
if (DefaultSpan.getInvalid().equals(span)) { | ||
if (!span.isValid()) { |
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.
Slightly incorrect, as in OT it's possible to set an invalid Span (one with zero-ed ids) as the active instance. We should check against Span.getInvalid()
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 you think you can give me a unit test that fails with the current code? OTel has many invalid checks, for example in instrumentation - I'd be surprised if we could even support a zero'd but live span in OTel. I'm guessing OT would propagate such a span, but OTel won't - so maybe we can just unify this behavior with the OTel semantics? Anyways a unit test would probably make things very clear, I'm not changing it back if we can't get the current code to fail first :)
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.
Another way to phrase my point of confusion - I would think returning a singleton for an invalid span is a performance optimization but wouldn't expect any behavior change. So if the use of a singleton is relied on here, it's unexpected and seems fragile. If it's required I need to add some more detailed docs.
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.
Not supporting valid spans with all zero trace or span ID is something that irks me about OTel actually, see open-telemetry/opentelemetry-specification#753
Separated out #1791 so closing this |
While open-telemetry/opentelemetry-specification#999 won't be merged, I think we can say that we have
SpanContext
, it just happens to be merged intoSpan
as an implementation detail.The API seems to be vastly simplified by this change. Far less dancing, no creating a
Span
just to have a container for storing inContext
- we always just work withSpan
s. No need to explain to users what the difference betweenSpanContext
andContext
is, we only have one context. How to link to a span? Add a link to the span.I noticed that we use
DefaultSpan
for three purposes currentlySpan.getPropagated
Span.getUnsampled
, though not sure it's a better name thanSpan.getNoop
Span.getPropagated
for most of these though it's not technically precise, but we could just as easily define a test utility for this and I don't think it's a huge dealLet me know any thoughts. Will finish up with javadoc if seems ok.
Fixes #1704
Fixes #1135