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.

[irenepeggy]

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

Actually, from class MultiTextMapPropagator I was expecting support for multi span context since multi Propagators could be passed there. Or maybe I misunderstand what that class serve for?

[jkwatson]

The purpose of MultiTextMapPropagator is to be able to process different possible formats. So, mostly for support for legacy propagation formats, as well as the W3C. It's not to be able to propagate different span contexts simultaneously.

If you had something like this, what context would you get if you called Context.current()? It would have to return more than one, and then what would you do with that? This would open up so many cans of worms, that I'm nearly 100% sure we will never implement anything like this without some very very clear direction from the specification about how it would behave.

[irenepeggy]

Thank you for the detailed explanation, now it's clear

Just in a case you are interested, I was intending to provide multiple contexts because of migration from B3 to W3C, which means that we need to support both of them for a while. Finally, we have implemented a custom multi propagator for that purpose

So as for me, it could be useful and not so vulnerable to support more than one context. But of course it's all up to you :)