proposal: Introduce Trace context Propogation - #4
Conversation
shaneutt
assigned
leseb and
franciscojavierarceo and unassigned
leseb and
franciscojavierarceo
praxis-bot
left a comment
praxis-bot
left a comment
There was a problem hiding this comment.
5 findings (1 critical, 2 large, 2 medium). The proposal is well-motivated and the What/Why sections are clearly scoped. Main blockers: missing required discussion link, incomplete W3C Trace Context coverage (tracestate omitted), and the issue field pointing to a PR rather than a tracking issue.
|
|
||
| - `x-request-id` — request correlation ID used primarily for logs and | ||
| support/debugging. | ||
| - `traceparent` — W3C Trace Context header used to continue a |
There was a problem hiding this comment.
[Large] The W3C Trace Context specification defines two headers that conforming implementations must propagate together: traceparent and tracestate. Per Section 3.3 of W3C Trace Context Level 1: "If a tracing system receives a W3C Trace Context with a traceparent header, it MUST propagate the tracestate header if received."
The proposal only lists traceparent. Add tracestate to the propagated headers list, or explicitly list tracestate as a non-goal with rationale for why partial W3C conformance is acceptable at this stage.
| absent or malformed. | ||
| - Propagate `x-request-id` and `traceparent` to the forwarded upstream | ||
| request when enabled. | ||
| - Propagate `x-request-id` and `traceparent` to subrequests |
There was a problem hiding this comment.
[Medium] The W3C spec requires each participating system to update the parent-id field in traceparent to produce a hierarchical trace graph. If subrequests copy traceparent verbatim, the trace topology will be flat -- all legs appear as siblings rather than children of the originating request.
Add a goal or note clarifying the intended span relationship: should subrequests generate a fresh parent-id (proper parent-child hierarchy in Jaeger/Tempo) or propagate traceparent unchanged (flat correlation only)? This distinction fundamentally affects trace topology and should be stated in the What, even if the mechanism is deferred to the How.
3a86327 to
0084c01
Compare
Signed-off-By: Vaishnavi Hire <vhire@redhat.com>
0084c01 to
7841ca7
Compare
praxis-bot
left a comment
praxis-bot
left a comment
There was a problem hiding this comment.
PR Review (Follow-up)
Summary: The discussion and issue tracking links are now correct. However, two W3C Trace Context conformance issues from the previous review remain unaddressed: tracestate header propagation is still missing, and the proposal does not clarify whether parent-id will be updated to create hierarchical traces.
| Severity | Count |
|---|---|
| Large | 1 |
| Medium | 1 |
| - `x-request-id` — request correlation ID used primarily for logs and | ||
| support/debugging. | ||
| - `traceparent` — W3C Trace Context header used to continue a | ||
| distributed trace across services. |
There was a problem hiding this comment.
[Large] The W3C Trace Context specification (Level 1, Section 3.3) defines two headers that conforming implementations must propagate together: traceparent and tracestate. The spec states: "If a tracing system receives a W3C Trace Context with a traceparent header, it MUST propagate the tracestate header if received."
The proposal lists only traceparent (line 52). The tracestate header carries vendor-specific trace context that must not be dropped when forwarding or creating subrequests.
Either:
- Add
tracestateto the propagated headers list (lines 47-52) and Goals (lines 65-71), or - Explicitly list
tracestateas a Non-Goal with rationale for why partial W3C conformance is acceptable at this stage (e.g., "v1 propagatestraceparentonly;tracestatedeferred to post-v1 after OTel integration is validated").
| - Propagate `x-request-id` and `traceparent` to the forwarded upstream | ||
| request when enabled. | ||
| - Propagate `x-request-id` and `traceparent` to subrequests | ||
| transparently through the default subrequest path when enabled. |
There was a problem hiding this comment.
[Medium] The W3C Trace Context spec requires each participating system to update the parent-id field in traceparent when creating child spans to produce a hierarchical trace graph. If subrequests copy traceparent verbatim (without updating parent-id), all trace legs will appear as siblings rather than children of the originating request in tools like Jaeger or Tempo.
Line 70-71 states "Propagate x-request-id and traceparent to subrequests" but does not clarify whether propagation is verbatim or involves parent-id generation.
This distinction fundamentally affects trace topology and should be stated in the What/Why phase. Add a note or Goal clarifying the intended span relationship:
- "Subrequests generate a fresh
parent-idto create proper parent-child hierarchy in distributed traces", or - "v1 propagates
traceparentunchanged for flat correlation; hierarchical span relationships deferred to future OTel span integration."
This is not an implementation detail — it's a core design choice that affects whether the feature delivers hierarchical tracing or just correlation.
6 participants
What does this PR do?
Discussion link
Checklist