You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your improvement related to a problem? Please describe.
Currently, in a send-only endpoint that doesn't have OpenTelemetry enabled, any outgoing message will still be enriched with the traceparent header with the Activity.Current.Id if a current activity is available.
The question is whether that's the desired behavior. Given that OpenTelemetry is not enabled on the (send-only)endpoint, one could argue that that's a choice not to propagate tracing info through headers.
Due to this behavior, there's currently no way to avoid the traceparent header from being added to outgoing messages when there's an ambient activity.
Describe the suggested solution
Describe alternatives you've considered
Alternative 1: Modify the default behavior so that when OpenTelemetry is not enabled on the endpoint, no traceparent header is ever added to the outgoing messages. However, in the context of an incoming message, the outgoing message should propagate the traceparent header to respect the previous propagation decision.
Alternative 2: Keep the default behavior, but provide an opt-in setting to avoid the traceparent header from being added on outgoing messages (unless it was already there in the incoming message, if running in the context of an incoming message).
Alternative 3: Keep the status quo.
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Describe the suggested improvement
Is your improvement related to a problem? Please describe.
Currently, in a send-only endpoint that doesn't have OpenTelemetry enabled, any outgoing message will still be enriched with the
traceparent
header with the Activity.Current.Id if a current activity is available.The question is whether that's the desired behavior. Given that OpenTelemetry is not enabled on the (send-only)endpoint, one could argue that that's a choice not to propagate tracing info through headers.
Due to this behavior, there's currently no way to avoid the
traceparent
header from being added to outgoing messages when there's an ambient activity.Describe the suggested solution
Describe alternatives you've considered
Alternative 1: Modify the default behavior so that when OpenTelemetry is not enabled on the endpoint, no
traceparent
header is ever added to the outgoing messages. However, in the context of an incoming message, the outgoing message should propagate thetraceparent
header to respect the previous propagation decision.Alternative 2: Keep the default behavior, but provide an opt-in setting to avoid the
traceparent
header from being added on outgoing messages (unless it was already there in the incoming message, if running in the context of an incoming message).Alternative 3: Keep the status quo.
Additional Context
No response
The text was updated successfully, but these errors were encountered: