Link api - to add links to span.#342
Conversation
Codecov Report
@@ Coverage Diff @@
## master #342 +/- ##
==========================================
- Coverage 94.57% 94.39% -0.19%
==========================================
Files 150 150
Lines 6768 6815 +47
==========================================
+ Hits 6401 6433 +32
- Misses 367 382 +15
|
| * @param attributes Link attributes | ||
| */ | ||
|
|
||
| virtual void AddLink(const trace::Link &link) noexcept = 0; |
There was a problem hiding this comment.
Could we go without the dedicated trace::Link type altogether? We don't have a type for events, so leaving this out for links would make things more symmetrical.
There was a problem hiding this comment.
Just thinking about scenarios which makes it different from Events, and having trace::Link would be helpful.
- Creating a link, and then associating it with multiple spans. It would be helpful to have link as an entity in that case.
- Link should be associated with the Span during it's creation, and not afterwards. As per the specification
"Links cannot be added after Span creation." With link type, it's helpful to pass sequence of links inSpanconstructor. Currently we do provideSpan::AddLink()but it needs to be called immediately after the span creation ( probably this needs to be clearly documented).
There was a problem hiding this comment.
Links cannot be added after Span creation.
I see. What do you think about completely dismissing AddLink methods, and just adding links via StartSpanOptions? This would enforce the spec requirement, I think this is a better and less ambiguous way to add links.
trace::Link as it is now is not useful. An API user couldn't even construct a trace::Link, as it's a pure interface.
There was a problem hiding this comment.
@pyohannes - I agree on dismissing AddLink methods. But sending links via StartSpanOptions won't be feasible, as we need to initialize collection of links. Using std::vector/std::array may break the ABI. Better option would be to have as separate argument in StartSpan :
nostd::shared_ptr<Span> StartSpan(nostd::string_view /*name*/,
const KeyValueIterable & /*attributes*/,
const StartSpanOptions & /*options*/,
const nostd::span<nostd::shared_ptr<Link>>& /*links*/) noexcept override
I don't have strong opinion in having dedicated Link type, but since link contains attribute pairs , and so the overloading for KeyValueIterable can be done within Link type, instead of adding more overloaded StartSpan methods. Let me know what you think ?
There was a problem hiding this comment.
I like the suggestion of having this as additional argument to the StartSpan function. I'm not yet sure about the best way to realize this, but let's work towards that!
There was a problem hiding this comment.
There was a problem hiding this comment.
@pyohannes - I have done the changes as separate PR #351 , as this was mostly a rework. Please review that PR. I am closing current PR.
|
Closes #319. |
| start_steady_time{options.start_steady_time}, | ||
| has_ended_{false} | ||
| { | ||
| (void)options; |
There was a problem hiding this comment.
Not sure why this is added back, should be removed because it was referenced in line 108 and 109.
There was a problem hiding this comment.
Yeah my bad . Thanks for pointing. Have raised a separate PR #351 as this was now a rework. Please review that. Will close this one.
| } | ||
|
|
||
| void Span::AddLink(const trace_api::Link &link) noexcept | ||
| { |
There was a problem hiding this comment.
Declare lock_guard(mf_) to make sure it is thread-safe?
There was a problem hiding this comment.
Have removed AddLink() as part of separate PR #351 . Please review that. thanks.
|
Was this supposed to be closed or merged? I cannot find a way to add links to Spans otherwise. |
You can add link while creating the span: Specs doesn't allow adding links once span is created. |
Update dependency rules_go to v0.55.1
As per the specification : https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#add-links.
TBD -> Need to fix test coverage, although it's passing in forked repo PR, it seems to fail here.