Trace context propagation
Passing trace IDs across HTTP, queues, and jobs so one request stays connected as it hops between services.
See it
What it is
Trace context propagation carries the identity of the current trace and span across a process boundary. Under the W3C Trace Context standard, an outbound caller injects a traceparent header and the receiver extracts it before starting its child span. That is what turns separate service timelines into one distributed trace. tracestate carries vendor-specific tracing data alongside it.
Reach for it anywhere work leaves the current process: HTTP clients, message queues, scheduled jobs, serverless invocations, and WebSocket messages. OpenTelemetry auto-instrumentation handles common libraries, but custom wrappers and message envelopes still need explicit inject and extract calls.
Gotcha: one missed boundary silently creates a new root trace, so both halves look healthy but never join. Test propagation across every transport. Treat incoming context as untrusted, and never put passwords, tokens, or personal data in W3C baggage because downstream services may forward it much farther than expected.
Ask AI for it
Implement trace context propagation with the OpenTelemetry SDK and the W3C Trace Context propagator. On every inbound HTTP request, extract traceparent and tracestate before creating the server span; on every outbound request, inject the current context into headers. Do the same for queue message properties around publish and consume, and restore context before starting worker spans. Preserve the sampled flag, reject malformed headers without failing the request, keep secrets and PII out of W3C baggage, and add an integration test asserting that an HTTP hop plus a queue hop produce one trace ID with the correct parent-child span chain.