When sending a message, the receive operation will be created as follows:
the send operation, creates a span (span A)
if the broker client SDK creates a span (span B), the NServiceBus receive span (span C) will be created as a child span to span B. The NServiceBus receive span (span C), will link to the original send span (span A).
if the broker client SDK doesn't create a span (there's no span B), a receive span (span C) will be created by NServiceBus as a child to the send operation (span A)
When publishing a message, the receive operation will be created as follows:
the publish operation, creates a span (span A)
if the broker client SDK creates a span (span B), the receive operation (span C) will be created as a child span to span B. Span C will be linked to the publish span (span A).
if the broker client SDK doesn't create a span (there's no span B), a new trace will be started, linking the new span (span C) to the publish span (span A).
So in short, if no telemetry is enabled on the broker client SDK, each receive of a send operation is created as a child span, and each receive of a publish operation results in a new trace that is linked to the original publish span.
This PR also introduces 2 API's to deviate from the default behavior:
One that allows you to create a new trace when receiving a send operation (through SendOptions.StartNewTraceOnReceive()), therefore not creating a child span, but linking to the send span instead.
One that allows you to create a child span when receiving a publish operation (through PublishOptions.ContinueTraceOnReceive()), therefore not creating a new trace, but rather creating a child span instead.
Addresses:
The default behavior is as follows:
So in short, if no telemetry is enabled on the broker client SDK, each receive of a send operation is created as a child span, and each receive of a publish operation results in a new trace that is linked to the original publish span.
This PR also introduces 2 API's to deviate from the default behavior: