-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Incorrect API behavior in absence of SDK #1893
Comments
Validation test:
|
Does this address #877? Based on my reading of it, it means that if I have, for example:
If I don't register an SDK, but do register a propagator, we would still extract context from http headers. Then, the StartSpan calls in the handler, code, and transport don't change the SpanContext in the context. Then, the context is encoded into outgoing http headers in the transport. The tracecontext headers in the incoming request should match the headers in the outgoing request, right? Or am I reading this incorrectly? |
Yes, this is correct. 👍
Yeah, I think it does. @dashpole based on your understanding outlined above, should I resolve that issue with #1901 as well? |
Yes, you should. It would be nice to document the "Passthrough" use-case, and potentially provide an example |
Tracking with #1908 |
Description
The specification states
Spans created in a trace tree that originates with a propagator correctly implement this, they are, at the root, a non-recording span (that is stored in a context). Spans created via a
Tracer
prior to an SDK being set that implements the API do not. They only are no-op spans that do not handle any part of the `SpanContext.Expected behavior
The API correctly implements the specification and will generate a non-recording span with the global
Tracer
prior to an SDK being set.The text was updated successfully, but these errors were encountered: