Add requirements for how the Trace API should behave in the absence of an SDK #719
Conversation
specification/trace/api.md
Outdated
| requested parent SpanContext: | ||
|
|
||
| * A valid SpanContext is specified as the parent of the new Span: The API MUST treat this parent context as the | ||
| context for the newly created Span. This means that a SpanContext that has been provided by a configured Propagator |
There was a problem hiding this comment.
Bit confused here.. This section is talking about the scenario when there is no Sdk installed. In that scenario, should we still take and propagate the context? Is this propagation limited to in-proc spans only or out-of-proc as well?
There was a problem hiding this comment.
So, yes, that's the point of this PR. :) Since you can install a Propagator without an SDK installed, it became important to explain how that would work. If a propagator (let's say, the W3C Trace Context propagator) is installed, this specifies that that API should still propagate incoming spans, transparently.
It's the "minimum" requirement from the W3C spec for forwarding a trace: https://www.w3.org/TR/trace-context/#design-overview
There was a problem hiding this comment.
It's the "minimum" requirement from the W3C spec for forwarding a trace
If you have no API and no SDK you are not a participant in the trace and thus not accountable to minimum behaviors.
There was a problem hiding this comment.
But, if you have propagators attached to the API, shouldn't you be?
|
This is not possible to implement in javascript without moving a ton of in-process context propagation logic into the API. Why is it that one use-case gets special treatment of being enabled by default? |
I don't see that agreement. Can you point to a specific comment? I also looked through the associated #428 and saw only no-op there in the absence of the SDK. |
Well, that entire issue is about the behavior of the API with no SDK, so yes, it seems like general agreement was come to, and I agreed to own writing up the results of the discussion. |
bogdandrutu
added
area:api
|
|
||
| In general, in the absence of an installed SDK, the Trace API is intended to a "no-op" API. | ||
| This means that operations on a Tracer, or on Spans, should have no side effects and do nothing. However, there | ||
| is one important exception to this general rule, and that is related to propagation of a SpanContext. |
There was a problem hiding this comment.
This part will probably change, based on #721
There was a problem hiding this comment.
You should be able to install a W3C propagator into the propagation layer (which is supposed to be an artifact separate from API) even without initializing the SDK, right? So I don't think this part changes?
There was a problem hiding this comment.
I agree. I don't think this changes. IF there is a propagator installed in the propagation APIs, THEN, this requires the API to propagate any valid spans that are specified as parent spans, even if no real child-span is created.
|
Thanks for the effort - I'm wondering if this should also be added to Metrics/CorrelationContext parts as well. |
|
@jkwatson please rebase and either remove draft or close this PR, we provided enough "initial" feedback :) |
|
I'll update this and get it ready for official review/merging. |
jkwatson
force-pushed
the
trace-api-only-behavior
branch
from
7c9a178
to
11981c9
Compare
|
Rebase again :) |
Co-authored-by: Christian Neumüller <christian+github@neumueller.me>
jkwatson
force-pushed
the
trace-api-only-behavior
branch
from
11981c9
to
3287d34
Compare
done :) |
|
I think there is an issue with GitHub status checks |
|
This looks ready to go. Can we merge? |
|
@carlosalberto as assigned member please merge or comment :) |
|
Merging this since it is non controversial. @jkwatson we should have similar content for all the APIs |
Clarifies the behavior of the Trace API, in the absence of an installed SDK, especially with respect to context propagation.
Fixes #689
Changes
Adds requirements for Trace API behavior in the absence of an SDK.