[BUG] - Trace ParentId is not restored from Diagnostic-Id message property

Library name and version

Azure.Messaging.ServiceBus 7.10.0

Describe the bug

I’m investigating W3C context propagation over ServiceBus. It looks like message sent correctly with valid Diagnostic-Id is not correlated correcly during the message read handling. For both servicebusreceiver.receive and servicebusprocessor.processmessage operations the ParentId property is null. Because of that, these operations are reported as separated traces instead of one trace, started on the web api request.

I tried to set ParentId manually with lines like:

    private async Task ProcessorOnProcessMessageAsync(ProcessMessageEventArgs arg)
    {
        var bodyAsString = arg.Message.Body.ToString();
        var diagnosticsId = arg.Message.ApplicationProperties["Diagnostic-Id"].ToString();
        using var activity = new Activity("ServiceBusProcessor.processing");
        activity.SetParentId(diagnosticsId);
        activity.Start();

        [...]
        activity.Stop();
    }

but it moves only user-code to the correct trace. Both servicebusreceiver.receive and servicebusprocessor.processmessage operations are received outside of the flow

Expected behavior

ServiceBus reader (both processor and receiver) should use TraceId from Diagnostic-Id as a ParentTraceId

Actual behavior

servicebusreceiver.receive and servicebusprocessor.processmessage don’t read ParentTraceId

Reproduction Steps

Available at https://github.com/lukasz-pyrzyk/opentelemetry-demo, API and webjob project, together with HTTP request to start the flow.

Environment

No response

[jsquire]

Is there a chance that the article comes from the times of Microsoft.Azure.Servicebus, where this approach was used

I don’t know the origin of the article nor who maintains it, but the code samples appear to have been updated for the current generation and I notice that our telemetry expert is listed as a contributor. @lmolkova: Would you be so kind as to offer your thoughts?

[msftbot[bot]]

Hi @lukasz-pyrzyk, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.