[BUG] Trace Context Not Propagating with Azure Service Bus Binder Using Micrometer Tracing and Brave

[wiZzwise]

I’m using Spring Cloud Stream with the Azure Service Bus binder, Micrometer Tracing, and Brave to trace messages across microservices. When sending a message from a producer to a consumer via Azure Service Bus, the trace context (e.g., traceparent) isn’t propagating correctly. The receiver starts a new trace instead of continuing the sender’s trace, breaking end-to-end visibility. This works as expected with the Kafka binder.

This suggests the Azure Service Bus binder isn’t correctly extracting traceparent from applicationProperties and setting it as the current Brave context before invoking the consumer

Contrast with Kafka

Kafka Binder: Extracts traceparent from Kafka headers, maps it to Spring Message headers, and Brave’s W3C propagation reads it, linking the trace.

Azure Binder: Passes traceparent to message.getHeaders(), but fails to set the Brave context, so Brave starts a new trace.

The issue is in the binder’s extraction logic: it’s not bridging traceparent from applicationProperties to Brave’s tracing context, unlike Kafka’s binder.

Steps to Reproduce:

Set up two Spring Boot applications with Spring Cloud Stream and the Azure Service Bus binder.

Configure Micrometer Tracing with Brave .

Create a producer and consumer using functional bindings.

Send a message withe traceparent and observe the traces logs

Any help Please !

[github-actions]

@anuchandy @conniey @lmolkova

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[lmolkova]

@saragluna could you please take a look? We support OpenTelemetry, but not Brave on the Azure ServiceBus SDK level so I assume there is something in the binder that makes it work with Brave at all.