Let's have a following scenario:

1. Execute 2 POST calls method on an deployment's endpoint (providing a rm message as a parameter)
2. Endpoints calls service that send the message to an emiter
3. Same service receive message from the same channel

MP Config:

mp.messaging.outgoing.source.connector=smallrye-amqp
mp.messaging.outgoing.source.address=testamqp

mp.messaging.incoming.sink.connector=smallrye-amqp
mp.messaging.incoming.sink.address=testamqp 

If I configure OpenTelemetry so that it traces only incoming channel, traces have incorret traceid and are organized incorrectly:

trace id: d5dd2c57227f8e9a91772bd84703ff90
span operation name: POST /mp-rm-amqp-otel/
-------------------------------------------
trace id: 4ab3e9dfe23e2352d7b51fffd32b300f
span operation name: testamqp receive
-------------------------------------------
trace id: 7caf9cdd8fd3a796baa673002d948db4
span operation name: POST /mp-rm-amqp-otel/
-------------------------------------------
trace id: 82dc9757b5022001b4ae1948c0568532
span operation name: testamqp receive

Address (or topic) is obviously "testamqp" and connector is "smallrye-amqp"

I expect POST /mp-rm-amqp-otel/ and testamqp receive to have the same trace ID.

This behavior is observable in following configurations:

It seems trace IDs are messed up when traces for the outgoing channel are disabled and enabled for the incoming channel. Other way around works fine (outgoing enabled & incoming disabled)