API for response headers

[yurishkuro]

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.

[carlosalberto]

This sounds to me like something we should do after GA.

[meastp]

is this a duplicate of #3811?

[dyladan]

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.

[meastp]

@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.

[austinlparker]

Discussion has mostly moved on to #3811 and #3825; Closing this in favor of those.

[yurishkuro]

Discussion has mostly moved on to #3811 and #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?

[arminru]

@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.

[yurishkuro]

#3811 is a different issue. #3825 would address this but it's not an issue, it was a PR that is closed.

[jpkrohling]

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.

[jack-berg]

From my side, it all could be tracked via #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.

[yurishkuro]

@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.