[instrumentation-amqplib] possible bug with baggage propagation while using span links on consume

[slittle-tn]

What version of OpenTelemetry are you using?

• api 1.9.0
• sdk-node 0.57.0
• instrumentation-amqplib 0.46.0

What version of Node are you using?

23.9.0

What did you do?

I can't share the actual code, but the gist is this:

• Configured the AMQP instrumentation with useLinksForConsume: true
• Added a value to the Baggage (in a non-Node service)
• When consuming the message (in Node), attempted to log the baggage value

What did you expect to see?

The value added to the baggage

What did you see instead?

The value was undefined

Additional context

This all hinges on if the baggage should still propagate even if we're in a new trace, which I believe is true, but if not then this isn't a bug.

I confirmed in the RabbitMQ console that the baggage header was there as expected prior to consuming, so it's not about the non-Node implementation.
The issue goes away without useLinksForConsume: true

I looked at the code a bit (getConsumePatch()), and I think the issue is that when span links are enabled the full parent context is set to undefined in order to start a new trace, but that context includes both the span context and the baggage. I'm not sure how all of it works, but I was able to get the baggage to propagate as expected by

1. Removing the parentContext = undefined line
2. Adding root: true to the options in the call to tracer.startSpan()

Basically trying to reset the span context without losing anything else in the context. That may not be the correct/complete solution though.

[dyladan]

I looked at the code a bit (getConsumePatch()), and I think the issue is that when span links are enabled the full parent context is set to undefined in order to start a new trace, but that context includes both the span context and the baggage.

This seems correct to me, but I'm not sure what the expected behavior would be in a lot of cases. If you consume multiple messages that have conflicting baggage what would you expect to happen? Should it be merged? What if 2 baggage entries have the same key with differing values?

I think this is something that would need some spec consideration in order to make this work the same in all languages. We really can't just implement this.

[slittle-tn]

I see what you're saying about something that consumes multiple messages being a potential issue. There is a section in the OTel spec that discusses Baggage conflict resolution (new value replaces an old value), and off the top of my head it seems like that would make the baggage in a process that consumes multiple messages depend on the consumption order.

That said, if you're only consuming a single message I'd expect the baggage to propagate—if that expectation is correct then the case of a consuming a single message still seems like a bug even if the case of multiple message consumption is less clear.