opentelemetry-specification
opentelemetry-specification copied to clipboard
open-telemetry
API for response headers
What are you trying to achieve?
Similar to OpenTracing and OpenCensus, the context in OpenTelemetry is only propagated forward, from caller to callee. However, some tracing systems instrument both directions, and may even require different IDs to be sent in the response, in order to explicitly capture the causality via events on a DAG. The OTEL API for Propagators currently provides no ability to distinguish whether the context is being serialized for the purpose of shipping it downstream or upstream.
Should there be some facility in the Propagator API to account for that?
Additional context.
Somewhat similar issue will arise when people try to implement the W3C Trace Context Response Header.
I think #3811 is more of a duplicate of this, but they're slightly different. This issue asks for the propagators API to include a general mechanism for response headers, and #3811 asks for a specific one.
@dyladan right, thanks for the clarification. I hope this will be standardised soon - it will be useful to return the traceid to clients even when there is no propagation, so the client can attach the traceid to bugs/issues.
Discussion has mostly moved on to #3811 and https://github.com/open-telemetry/opentelemetry-specification/pull/3825; Closing this in favor of those.
Discussion has mostly moved on to https://github.com/open-telemetry/opentelemetry-specification/issues/3811 and https://github.com/open-telemetry/opentelemetry-specification/pull/3825; Closing this in favor of those.
@austinlparker One of those is closed, another is discussing wire format. Neither cover the question raised in this issue - how can instrumentation actually use propagators to inject baggage into response.
@arminru why is it "not planned"? How do we plan to support W3C response header?
@yurishkuro I marked it as a duplicate of the two tickets as stated above, so this one shows up as Closed in gray.
Otherwise the default purple "☑️ Completed" would give a first impression that this was already implemented and would be available now.
If this issue turns out not to duplicate the others, it could be re-opened and discussed further, of course.
#3811 is a different issue. #3825 would address this but it's not an issue, it was a PR that is closed.
They all have the same purpose. #3811 requires #1355, which is what #3825 attempts to address first.
From my side, it all could be tracked via #3811 for simplicity, but perhaps the TC can triage this.
From my side, it all could be tracked via https://github.com/open-telemetry/opentelemetry-specification/issues/3811 for simplicity, but perhaps the TC can triage this.
Discussed in the 7/17/24 TC meeting. We're going to keep this around because although #3811 may solve this, the ask here is more general purpose / not as use-case specific as #3811.
@jpkrohling I think we should keep this one as a tracking. It states a problem that requires a new API (#3825 was a solution, but was closed). #3811 is related but goes into a completely different discussion about the format - a specific implementation detail of one possible implementation of the API. #3811 cannot be implemented without solving this issue, as you said, but the discussion there will completely side-track us.
Hello. Just wanted to share here that in my SIG (php) somebody is keen to have a response propagator mechanism so that they can use it to pass some vendor-specific headers back to the client (in this case, some sampling information from a custom sampler). The requirements sound like they match this issue, so there is some need for this.
Definitely there are needs for this. We can find different kind of response propagator interface already implemented in different language instrumentation. Python: set_global_response_propagator Ruby: response propagators in rack instrumentation JS: responseHook in opentelemetry-instrumentation-http
I am not sure if it is a good idea to standardize those API(s) as different language has its own specific implementation. While Python claimed it is an experimental propagator and others didn't, I think it is better to write up some sort of spec / guidance for this response propagator interface. So other language(s) can start thinking about the response propagator interface which works the best for them.
