[BUG] Why Are the Traces for Multiple Service Bus Messages Correlated Under Same Operation ID in Application Insights?

[SamuelBucheliZ]

Query/Question
As we regularly experienced issues similar to the following ones

• Client stop consuming messages form SB azure-service-bus-java#335
• [core-amqp] onTransportError does not retry to get AMQP Connection #21156
• [BUG] ASB consumer stops with "ReactorDispatcher instance is closed", only recovers after restart #25085

we have implemented a periodically scheduled reconnect of the ServiceBusProcessorClient

This reconnect looks roughly as follows

    @Scheduled(
            fixedRateString = "PT1H"
    )   
    public void reconnect() {
        try {
            processorClient.close();
        } catch (Exception e) {
            log.warn("Failed to stop existing Service Bus client", e);
        }

        try {
            processorClient = createClient(config, processMessage, processError);
            processorClient.start();
        } catch (Exception e) {
            log.error("Failed to create new Service Bus client", e);
        }
    }

This reconnect has fixed the issues mentioned above. However, since upgrading to azure-messaging-servicebus version 7.4.1 (from 7.3.0), we have experienced a problem w.r.t. tracing in Application Insights.

Specifically, we have noticed that now the tracing data in Application Insights for all messages handled by the ServiceBusProcessorClient instance created by the reconnect appears in the same transaction, i.e., has the same operation ID.

For example, here the handling hundreds of individual messages is all in the context of this initial reconnect method:

Is this expected behaviour? Is there any way to fix this on our side? Or is this a bug in the SDK?

We would expect that the handling of each message has its own operation ID, i.e., is in a separate transaction. The current view makes it very hard to analyze and debug problems due to the enormous number of traces in one transaction.

Why is this not a Bug or a feature Request?
At the moment, we are unsure whether this is a bug or whether we are using the SDK in a wrong way on our side.

Setup (please complete the following information if applicable):

• OS: Java Spring Boot Application deployed with Docker containers on Azure App Service with Linux Plan
• IDE: n/a
• Library/Libraries:

           <dependency>
               <groupId>com.azure</groupId>
               <artifactId>azure-messaging-servicebus</artifactId>
               <version>7.4.1</version>
           </dependency>

and applicationinsights-agent-3.2.0.jar

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

• Query Added
• Setup information Added

[pallavit]

/cc: @lmolkova, @conniey can you please take a look.

[ki1729]

@SamuelBucheliZ Tracing was/still is in beta for service bus. The previous implementation had a lot of issues, so we have added and updated a lot of traces (and metrics) in the service bus SDK in the last two releases. This should resolve the problem for you. Please do let us know if you face any issue in using tracing now.

[SamuelBucheliZ]

@ki1729 Thank you very much for the information. Unfortunately, I do not work on the project where this issue was raised anymore, so I'm not able to verify the fix. I have forwarded this information to the relevant people, however, and would suggest to close the issue at the moment.