Downstream services are producing spans, but instead of continuing the caller's trace they start new traces of their own. Walk through how you would diagnose a cross-service context-propagation failure.

## Establish the symptom precisely Two problems are routinely confused and they have disjoint causes. - **New trace id at the callee.** The callee did not extract a parent, so it started a root. This is propagation. - **Same trace id, missing spans in the middle.** Context propagated fine; something declined to record or export. This is sampling, exporter failure, or a dropped batch. Compare the trace ids on both sides of the suspect hop for the same logical request — correlate by request id, by timestamp, or by logging the trace id in application logs at each service. If the ids differ, continue with the propagation checklist below. If they match, stop and go look at samplers and exporters instead. ## Step 1: does the header reach the callee? Instrument the question rather than reasoning about config. Add a temporary debug log at the callee's ingress that records whether `traceparent`, `tracestate`, `b3` and `X-B3-TraceId` are present (log presence and the trace id, not full headers indiscriminately). Alternatively inspect at the proxy layer or capture traffic. **Header absent.** Candidates, roughly in order of frequency: - The caller's outbound path is not instrumented. Auto-instrumentation covers well-known clients; a hand-rolled client, a raw socket, a shell-out to a command-line HTTP tool, or a background job that constructs requests directly gets nothing. - The caller *is* instrumented but had no context to inject — an asynchronous hand-off dropped it inside the caller, so it injected an empty context. Check whether the caller's own span for that outbound call exists. - An intermediary removed it. API gateways that rebuild requests from an allowlist, service meshes with header policies, CDNs, WAFs, and load balancers configured to strip unknown headers all do this. Test by calling the callee directly, bypassing the intermediary, with a hand-crafted `traceparent`. **Header present.** Move to step 2. ## Step 2: format and configuration mismatch The most common cause of "header arrives, still a new trace" is that the two sides speak different propagation formats. Zipkin-lineage systems use B3, either as a single `b3: <traceid>-<spanid>-<sampled>` header or the multi-header `X-B3-TraceId` / `X-B3-SpanId` / `X-B3-Sampled` form; OpenTelemetry SDKs default to W3C `traceparent`/`tracestate`. A service configured only for W3C ignores a B3 header entirely, and the reverse is also true. Check the configured propagators on both sides (in OTel SDKs this is typically an environment setting listing the propagators to compose, or explicit code at SDK initialisation). During migration, configure a composite propagator that injects both formats and extracts whichever is present, then remove the legacy format once every service understands the new one. Note the cost: dual injection means more header bytes on every request, so treat it as a bounded migration state. Also check B3 sub-format mismatches — single-header versus multi-header — which fail the same way even when both sides say "we use B3". ## Step 3: validity and duplication Even a correctly named header can be rejected: - An all-zero trace id or span id is invalid by specification and must be ignored; some hand-written clients emit zeros as a placeholder. - Wrong lengths, uppercase hex, or a malformed version field make the header invalid. - A duplicated `traceparent` (two intermediaries each adding one) invalidates the context. - Case-sensitive header lookup in a custom getter can miss `Traceparent` from a non-conforming client. ## Step 4: extraction happened but was not used Occasionally the SDK extracts correctly and the application still roots a new trace. Causes: the server span is started *before* the extracted context is made current; framework instrumentation is registered after the handler that creates the span; or application code explicitly starts a span with a root parent, overriding what was extracted. Verify by logging the extracted trace id at ingress — if the log shows the caller's id but the exported span shows a different one, the problem is inside the callee's own span-start ordering, not on the wire. ## Step 5: think about trust, not just plumbing Sometimes the "failure" is deliberate. Perimeter services often strip inbound trace context so external callers cannot choose your trace ids or force the sampled bit. If traces reliably start at the edge gateway and nowhere earlier, confirm whether that is policy before you "fix" it. ## Prevention Make propagation a tested property rather than an observed one: a smoke test that issues a request with a known `traceparent` and asserts that every service in the path reports the same trace id; a dashboard of root-span rate per service (a service that should never be a root suddenly producing roots is the alarm); and a standard, centrally managed propagator configuration so no service quietly diverges.