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

Add Span#addLink, for adding link after span start #6084

Merged
merged 5 commits into from
Feb 7, 2024

Conversation

jack-berg
Copy link
Member

Implementation of new spec requirement to support adding links after span start, defined in: open-telemetry/opentelemetry-specification#3678

@jack-berg jack-berg requested a review from a team December 18, 2023 23:25
Copy link

codecov bot commented Dec 18, 2023

Codecov Report

Attention: 9 lines in your changes are missing coverage. Please review.

Comparison is base (8684882) 91.06% compared to head (4588c3c) 91.01%.

Files Patch % Lines
.../main/java/io/opentelemetry/sdk/trace/SdkSpan.java 68.00% 4 Missing and 4 partials ⚠️
...emetry/extension/incubator/trace/ExtendedSpan.java 50.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #6084      +/-   ##
============================================
- Coverage     91.06%   91.01%   -0.05%     
- Complexity     5671     5676       +5     
============================================
  Files           620      621       +1     
  Lines         16553    16580      +27     
  Branches       1689     1693       +4     
============================================
+ Hits          15074    15091      +17     
- Misses          993      998       +5     
- Partials        486      491       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@jack-berg
Copy link
Member Author

@jkwatson any additional comments? Thanks!

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.

🚢 tiny javadoc suggestion, but nothing major

@jack-berg
Copy link
Member Author

@jkwatson I was about to merge but double checked the stability status of the addLink and saw that it was experimental! So I refactored this PR a bit to move it to the incubating module instead.

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

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

Looks good overall, but had a couple of ideas about the interface.

@@ -35,7 +36,7 @@

/** Implementation for the {@link Span} class that records trace events. */
@ThreadSafe
final class SdkSpan implements ReadWriteSpan {
final class SdkSpan implements ReadWriteSpan, ExtendedSpan {
Copy link
Contributor

Choose a reason for hiding this comment

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

Something about this gives me pause -- because it is implementing two interfaces both of which extend a common parent interface. Seems weird to me. Maybe it's nothing, but it seems like a smell to me.

Immediately makes me question whether or not ExtendedSpan really needs to extend Span.

Copy link
Member Author

Choose a reason for hiding this comment

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

Initially I switched ReadWriteSpan to extend ExtendedSpan instead of Span, but that doesn't work because ReadWriteSpan is part of the public API, and we can't have experimental surface area exposed in the stable API.

We have a long history of doing non-ideal things to be able to incubate things without committing to the stable API. While this is a smell, it will be short lived as it goes away as soon as the spec stabilizes and these methods are promoted to span.

Immediately makes me question whether or not ExtendedSpan really needs to extend Span.

Any other ideas?

Copy link
Member

Choose a reason for hiding this comment

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

We have a long history of doing non-ideal things to be able to incubate things without committing to the stable API.

👍

Copy link
Contributor

Choose a reason for hiding this comment

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

Immediately makes me question whether or not ExtendedSpan really needs to extend Span.

Any other ideas?

What if it just didn't? It can be its own stand-alone interface, right? And it's only used by the single implementation.

Copy link
Member Author

@jack-berg jack-berg Feb 1, 2024

Choose a reason for hiding this comment

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

Well the idea is that a user casts spans to ExtendedSpan to access the the combination of stable and experimental methods:

ExtendedSpan span = (ExtendedSpan) tracer.spanBuilder("name").startSpan();
span.setAttribute("key", "value");
span.addLink(spanContext);

If ExtenedSpan doesn't extend Span, then its more awkward to use:

Span span = tracer.spanBuilder("name").startSpan();
span.setAttribute("key", "value");
// Cast span to ExtendedSpan just to access #addLink
((ExtendedSpan) span).addLink(spanContext);

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah ok, I get it. Thanks for clarifying.

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.

4 participants