[BUG] spring-cloud-azure: customizer-set ClientOptions (incl. TracingOptions) silently overwritten for Service Bus processors

[marcinsiennicki95]

Describe the bug

AzureServiceClientBuilderCustomizer<ServiceBusClientBuilder> is the documented extension point for customizing the underlying Service Bus client builder (it is even the workaround recommended in #43555). However, for @ServiceBusListener processors created by DefaultServiceBusNamespaceProcessorFactory, any ClientOptions set by such a customizer is silently discarded.

This makes it impossible to configure Azure SDK tracing (azure-core-tracing-opentelemetry + OpenTelemetryTracingOptions) for Spring Messaging Service Bus listeners, because TracingOptions can only travel via ClientOptions and cannot be expressed through configuration properties.

Root cause (traced in spring-cloud-azure_7.2.0 sources)

1. Root-builder customizers do run — customizeBuilder(...) is the last step of ServiceBusClientBuilderFactory.build(), so at that point the customizer's ClientOptions is set on the root ServiceBusClientBuilder.
2. The enclosing ServiceBusProcessorClientBuilderFactory (non-shared path, used by DefaultServiceBusNamespaceProcessorFactory#doCreateProcessor) then runs its own configureCore, and AbstractServiceBusSubClientBuilderFactory#consumeClientOptions() executes:

   if (!isShareServiceBusClientBuilder()) {
       getServiceBusClientBuilder().clientOptions(client); // properties-derived instance
   }

   replacing the customizer's ClientOptions with the sub-factory's own instance (populated only from properties, e.g. application id).
3. azure-messaging-servicebus creates the tracer from the root builder's clientOptions field only at buildProcessorClient() time (createTracer(clientOptions) in ServiceBusClientBuilder) — i.e. after the overwrite — so the tracing configuration never reaches the SDK instrumentation.

To Reproduce

Spring Boot app with spring-messaging-azure-servicebus, an @ServiceBusListener, and:

@Configuration(proxyBeanMethods = false)
class ServiceBusTracingConfig {
  @Bean
  AzureServiceClientBuilderCustomizer<ServiceBusClientBuilder> serviceBusTracingCustomizer(
      OpenTelemetry openTelemetry) {
    return builder ->
        builder.clientOptions(
            new ClientOptions()
                .setTracingOptions(new OpenTelemetryTracingOptions().setOpenTelemetry(openTelemetry)));
  }
}

The customizer executes (breakpoint confirms), yet no ServiceBus.* spans are ever emitted. Reproduced end-to-end with an integration test against the Service Bus emulator and an in-memory span exporter attached to the application's OpenTelemetry SDK: the listener's downstream spans (e.g. MongoDB) are exported, each starting a fresh root trace, while no Service Bus process/receive/settle spans appear and the producer's traceparent from the message application properties is never continued.

Expected behavior

ClientOptions set by a root-builder customizer should survive processor creation (customizers are documented to run last), or there should be a supported way to pass TracingOptions to processor clients created for @ServiceBusListener.

Setup

• spring-cloud-azure-dependencies:7.2.0, spring-messaging-azure-servicebus, azure-messaging-servicebus:7.17.17
• azure-core-tracing-opentelemetry:1.0.0-beta.64, OpenTelemetry Spring Boot starter 2.27.0 (SDK exposed as a Spring bean; GlobalOpenTelemetry intentionally not used)
• Spring Boot 4.0.6, Java 21

Additional context

The same guarded-redirect pattern in consumeClientOptions() applies to the other consume* methods, but ClientOptions is the only carrier of TracingOptions, so tracing is the visible casualty. Binding via GlobalOpenTelemetry instead is not a viable workaround because the plugin resolves the global eagerly at client build time, which conflicts with frameworks that never register it (e.g. the OpenTelemetry Spring Boot starter).

[github-actions]

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

//cc: @EldertGrootenboer @skarri-microsoft

[github-actions]

🎯 Agentic Issue Triage

Summary: ClientOptions set by an AzureServiceClientBuilderCustomizer (including TracingOptions for OpenTelemetry) is silently overwritten during processor client creation in AbstractServiceBusSubClientBuilderFactory.consumeClientOptions(), making it impossible to configure OpenTelemetry distributed tracing for @ServiceBusListener processors via the documented customizer extension point.

📋 Issue Details

Package: com.azure.spring:spring-messaging-azure-servicebus (via spring-cloud-azure-dependencies:7.2.0)
Affected API: AbstractServiceBusSubClientBuilderFactory.consumeClientOptions(), DefaultServiceBusNamespaceProcessorFactory.doCreateProcessor()
Scenarios:

• Configuring TracingOptions via AzureServiceClientBuilderCustomizer for @ServiceBusListener processors — customizer executes successfully (confirmed via breakpoint) but tracing options are silently discarded
• No ServiceBus.* spans are emitted; each downstream span starts a fresh root trace; the producer's traceparent from message application properties is never continued

Root ask: ClientOptions set by a root-builder customizer should survive processor client creation; or at minimum, consumeClientOptions() should merge TracingOptions from the customizer's instance rather than unconditionally replacing the entire ClientOptions object.

🔎 Debugging / Reproduction Notes

Root cause traced in spring-cloud-azure 7.2.0:

1. Root-builder customizers run correctly as the last step of ServiceBusClientBuilderFactory.build(), so ClientOptions (with TracingOptions) is set on the root ServiceBusClientBuilder
2. When DefaultServiceBusNamespaceProcessorFactory creates a non-shared processor, AbstractServiceBusSubClientBuilderFactory.configureCore() calls consumeClientOptions(), which executes:

   if (!isShareServiceBusClientBuilder()) {
       getServiceBusClientBuilder().clientOptions(client); // properties-derived instance only
   }

   — unconditionally replacing the customizer's ClientOptions with a new instance populated only from Spring properties (e.g., application id)
3. ServiceBusClientBuilder.createTracer(clientOptions) is called at buildProcessorClient() time, after the overwrite, so TracingOptions never reaches the SDK instrumentation layer

Suggested investigation steps:

1. Check whether consumeClientOptions() should merge individual fields (especially tracingOptions) from the existing ClientOptions into the properties-derived instance rather than replacing it entirely
2. Alternatively, check whether AzureServiceClientBuilderCustomizer should run after sub-factory configuration rather than only on the root builder
3. Review whether the same issue affects other consume* methods in AbstractServiceBusSubClientBuilderFactory for similar customizer-set properties
4. Reproduce with an integration test against the Service Bus emulator with an in-memory span exporter to verify fix

🏷️ Label Confidence

• Category: Client — this is a bug in the Spring Cloud Azure client library layer (AbstractServiceBusSubClientBuilderFactory), not a REST API or service behavior issue
• Service: Service Bus — the affected library is spring-messaging-azure-servicebus; confirmed by quality reference issue #41560 (identical context: @ServiceBusListener + spring-messaging-azure-servicebus, labeled Client + Service Bus)
• Confidence: High — the issue clearly names the affected Spring package and the root cause is within the Service Bus Spring integration layer; no ambiguity between services or categories

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Service Bus (line 465) — matched because the predicted "Service Bus" service label satisfies the single-label requirement of this entry
• AzureSdkOwners: none listed for this entry
• ServiceOwners: @EldertGrootenboer @skarri-microsoft
• Routing action: Added Service Attention and needs-team-attention labels; left unassigned (ServiceOwners path); owners notified via routing comment
• Scan notes: %Service Bus %Track 1 (line 469) was encountered first during bottom-to-top scan but skipped — the issue does not carry the "Track 1" label; continued upward to %Service Bus (line 465) which matched on "Service Bus" alone

Generated by Agentic Triage for #49742 · 66.5 AIC · ⌖ 13 AIC · ⊞ 11K · ◷