OTLP Receiver to OTLP Exporter: Does the OpenTelemetry Collector preserve incoming W3C tracestate entries unchanged?

Answer first

With a default OTLP receiver → OTLP exporter pipeline and no processors in between, the OpenTelemetry Collector core does not rewrite Span.TraceState. The string received from the SDK is stored as-is and emitted downstream unchanged. Traceparent and tracestate HTTP headers are not forwarded by the exporter; the exporter sends span data with the TraceState field populated.

Confirmed facts

• Core pass-through: The Collector core stores Span.TraceState as received and emits the same string downstream. It does not rewrite trace_id, span_id or trace_state for a pure pass-through.
• No syntactic validation in Collector: W3C tracestate syntactic validation is performed by SDK propagators on inbound HTTP headers, not by the Collector core on OTLP span data. The Collector does not drop or reject spans because tracestate fails W3C syntax.
• Header vs span data: An OTLP exporter does not forward incoming traceparent/tracestate HTTP headers. Header preservation only applies when the Collector itself propagates context via its own HTTP client using a W3C propagator, which is distinct from OTLP span forwarding.

Likely behavior, not guaranteed

• Deduplication: The Collector core does not automatically deduplicate identical tracestate key-value pairs. Deduplication would require an explicit processor. Otherwise original ordering and duplicates are retained.
• Size limits: The Collector core does not enforce a hard W3C tracestate size limit for OTLP export. Truncation or rejection of oversized tracestate typically occurs in backends or exporter-specific limits, not in the Collector pass-through. Attribute and span size limits can affect export if configured.

Assumptions and uncertainty

This assessment assumes no processors between receiver and exporter, and a current Collector core release. Attribute, span, or resource processors, tail sampling, batching with limits, or contrib exporters can modify or drop TraceState. Behavior is version-sensitive.

Verification steps for this case

1. Inspect pipeline config for any processors between otlp receiver and otlp exporter that touch span attributes or trace state.
2. Emit a test span from the originating SDK with a known tracestate value and compare the tracestate string on the downstream backend byte-for-byte with the SDK-emitted value.
3. Enable Collector debug logging and export a single span with a known tracestate to observe the received and exported Span.TraceState.

To give a definitive recommendation for your deployment, please confirm the Collector version and the exact pipeline config between the otlp receiver and otlp exporter, specifically whether any processors are present.