[feature request] Looking for a way to avoid traceparent header rewriting. #2440
Labels
comp:instrumentation.http
Things related to OpenTelemetry.Instrumentation.Http
enhancement
New feature or request
Component
OpenTelemetry.Instrumentation.Http
Is your feature request related to a problem?
HttpHandlerDiagnosticListener
propagates/rewrites context irrespective of sampling decision and presence oftraceparent
header.In our company we have custom client library built around HttpClient for some internal purposes. We manually create Activity and manually add
traceparent
header before request execution, and then suppress instrumentation withSuppressInstrumentationScope.Begin()
to force underlying HttpClient to not emit it's own events to avoid duplication.There is a problem when someone uses that library with Opentelemetry.Instrumentation.Http enabled:
HttpClient creates Activity despite the instrumentation suppressed, but doesn't touch
traceparent
if it already present. Although this Activity will not be recorded, it falls intoHttpHandlerDiagnosticListener
which rewrites present and validtraceparent
header. This leads to trace corruption.Why such behaviour was chosen? Do I have any options to change it?
What is the expected behavior?
Check presence of
traceparent
header before rewriting it like runtime DiagnosticsHandler does.Which alternative solutions or features have you considered?
Add some settings to choose which behaviour to use.
Additional context
Besides current issue, it's not obvious to me why HttpClient fallback to Activity creation even if the sampler's decision is to drop it. I am trying to supress it, but as a result Activity is still being created. Moreover, it is created with
Recorded == true
property, but it will not be recorded actually.The text was updated successfully, but these errors were encountered: