Unexpected behavior of MultiTextMapPropagator

[irenepeggy]

Describe the bug
MultiTextMapPropagator share the same SpanContext between it's propagators, that leads to overwriting values of traceId and maybe some other thacing information

Steps to reproduce
I initiated MultiTextMapPropagator with B3Propagator and W3CTraceContextPropagator since our service need to provide both W3C-headers and B3-headers, and I used to inject and extract SpanContext

What did you expect to see?
I expected the headers X-B3-TraceId and traceId (of W3C-tracing) to remain the same after the propagation

What did you see instead?
In the logs of our service I observed X-B3-TraceId with a different value. It looked like it was overwritten by a new one, while traceId of W3CTraceContextPropagator was propagated correctly

What version and what artifacts are you using?
Artifacts: opentelemetry-api, opentelemetry-sdk, opentelemetry-extension-trace-propagators, opentelemetry-exporter-otlp, opentelemetry-semconv)
Version: 1.43.0 for all except of opentelemetry-semconv ( here we use 1.23.1-alpha)
We reference these artifacts with build.sbt

Additional context
So I tried to understand what's going wrong and looked through the source code of a MultiTextMapPropagator. There I found out that after deserialization both X-B3-TraceId and traceId (of W3C) are store in the traceId of the same SpanContext, so I consider that collission is the cause

I hope you would have the opportunity to take a look at that issue soon
Thank you!

[jkwatson]

What exactly were you expecting? If you have two different trace ids on a single request, which one should win? A single propagator can only create a single SpanContext from an incoming request, so there is no other option but to have one win (or, I suppose, throw them both out and lose all tracing information, but that seems worse to me).

This is working as expected. If you need some other behavior, you will probably have to implement it yourself, as it wouldn't make sense from an OTel perspective to do anything but choose one and use that as the parent trace id.

[breedx-splk]

If you have two different trace ids on a single request, which one should win?

I think what the original submitter is expecting is that neither should win and that both should be propagated outward, irrespective of how opentelemetry propagation is designed.

So yeah, I also think this will require manual implementation to do the thing that is being described. There is probably room to reuse the two implementations (b3, w3c), but you'd need to call manage multiple contexts simultaneously, which is not something otel ever wants to do for a single operation/request.