search

open-telemetry / opentelemetry-specification

Specifications for OpenTelemetry
https://opentelemetry.io
Apache License 2.0
3.71k stars 887 forks source link

API for response headers #1355

Open yurishkuro opened 3 years ago

yurishkuro commented 3 years ago

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 commented 3 years ago

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

meastp commented 5 months ago

is this a duplicate of #3811?

dyladan commented 5 months ago

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 commented 5 months ago

@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 commented 3 months ago

Discussion has mostly moved on to #3811 and https://github.com/open-telemetry/opentelemetry-specification/pull/3825; Closing this in favor of those.

yurishkuro commented 3 months ago

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?

arminru commented 3 months ago

@yurishkuro I marked it as a duplicate of the two tickets as stated above, so this one shows up as Closed in gray. image 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 commented 3 months ago

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

jpkrohling commented 2 months ago

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 commented 2 months ago

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.

yurishkuro commented 2 months ago

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