[BUG] Current trace context not recognized on first call to ServiceBusSenderClient.sendMessage()

[ragnaroh-nrk]

Describe the bug
The first call to ServiceBusSenderClient.sendMessage() does not recognize the current tracing context, and thus the span created when sending a message gets a new trace ID.

To Reproduce
See this repo: https://github.com/ragnaroh-nrk/azure-service-bus-tracing-issue

Expected behavior
The span created when sending a message should get the same trace ID as the current trace context.

Screenshots

Setup (please complete the following information):

• OS: iOS
• IDE: IntelliJ
• Library/Libraries: com.azure:azure-core-tracing-opentelemetry:1.0.0-beta.56
• Java version: 21
• App Server/Environment: Tomcat
• Frameworks: Spring Boot

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Bug Description Added
• Repro Steps Added
• Setup information Added

[alzimmermsft]

Thanks for filing this issue @ragnaroh-nrk

@lmolkova could you take a look into this?

[lmolkova]

thanks for reporting this @ragnaroh-nrk !

I believe what happens is that implicit context is not propagated to async client under ServiceBusSenderClient on the first call because the first call is when the connection establishment and other AMQP initial setup happens, so the first message instrumentation happens on the different thread where the implicit context is not available.

There are a couple ways to mitigate it:

• Enabling reactor instrumentation should mitigate it in the client code. It should be enabled by default when instrumenting with Java agent. Could you confirm you're not using codeless opentelemetry-javaagent ? Reactor instrumentation would propagate the context across threads in reactor, but it would come with some perf overhead.
• Using async client directly and passing OTel's parent context in the reactor context under trace-context key. To make things a little bit easier on the SDK side, we could have provided a sendMessage(s) overloads that take Context and then it would be possible to pass context over sync client, but that would be a massive change which might not be justified here.

[ragnaroh-nrk]

Hi @lmolkova , thanks for looking into this. I can confirm that I'm not using the javaagent (see linked repo above). It's not clear to me how I could pass OTel's parent context in the reactor context when using the async client. Do you have a code example?