TRACING · W3C TRACEPARENT
Trace integration: follow an outgoing traceparent
Follow one agent request through an HTTP tool call, an inventory service and a queue, and see where its trace context survives.
Your experiment
The tool injects a valid traceparent and the inventory service continues the trace, but the message it puts on a queue carries no trace context, so the worker starts a new trace. Count the traces the backend receives, then carry context through the queue, break the header and change the sampling decision.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Six fixed spans; trace and span ids are the example values from the W3C Trace Context specification plus two invented ids for new roots. The parser is strict (lowercase hex, version ff invalid, all-zero trace id invalid), as the specification defines; lenient libraries may differ. No OpenTelemetry SDK, collector or network is used, and the tracestate header and span links are not modeled.
One request, six spans
An agent invocation creates a root span, a model-call span and an HTTP client span for a tool. The tool calls an inventory service, which records a server span and publishes a message to a queue; a worker consumes it and records the last span. A trace connects them only if each hop carries the context: on HTTP the W3C traceparent header, version-traceid-parentid-flags, for example 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01. On a queue the context must travel in message attributes. The trace table shows each span’s trace id and parent.
The opening run: the queue splits the trace
The HTTP client injects a valid header and the inventory service extracts it, so its spans continue trace 4bf92f35… as children of client span 00f067aa0ba902b7. The queue message carries no context, so the worker starts a new trace, 0f1e2d3c… The backend receives all 6 spans in 2 traces, and no single view shows the request end to end. Turn on Queue message carries traceparent and the worker continues the inventory trace: 1 trace, 6 of 6 spans.
Failure boundary: headers a receiver must reject
With the queue fixed, change traceparent sent. An uppercase trace id, an all-zero trace id or version ff are not valid under the specification, so a strict receiver ignores the header and starts a new trace: the request splits into 2 traces again, even though a header was sent. Turning off Tool’s HTTP client injects traceparent or Inventory service extracts incoming context has the same effect at the HTTP hop, and with the queue still unpropagated the request ends up in 3 traces. A header that is present is not a header that was understood.
Sampling has to agree too
The last two hex digits are trace flags; 01 means the agent sampled the trace and recorded its spans. With Agent’s sampling decision at 00 and a downstream that follows the parent’s flag, nothing is recorded anywhere: consistently unsampled, which is the intended outcome. Turn off Downstream follows the parent’s sampled flag and the inventory service records its spans anyway, so the backend holds 3 of 6 spans whose root points to a parent that was never recorded: an orphaned subtree. With 00 and no queue propagation, only the worker’s new trace is recorded, disconnected from the request.
Reading the run and its limits
Play replays the root, the HTTP hop, extraction, the queue hop, collection and the outcome over sixty inspection seconds; Next event, Restart, Speed and Inspection time control the replay, and any input change recomputes it. Ids are the specification’s example values plus two invented roots. The parser here is strict as the specification defines; some libraries are more lenient. No OpenTelemetry SDK, exporter or collector is involved, and tracestate, baggage, span links for batch consumers and tail sampling are left out.