[BUG]: Span context not extracted from W3C Trace Context #6596
Assignees
Labels
Comments
|
@msciuto-photosi thanks a bunch for reporting and all of the context around this! Definitely looks like a bug present in both V2 and V3 as you've noted. I'll do some digging on this. |
bouwkast
added a commit
that referenced
this issue
Feb 21, 2025
## Summary of changes
The `W3CTraceContextPropagator` would check whether there was a single
`traceparent` header value to determine whether or not it should extract
W3C headers further. For non-standard array types it would _always_
return `false` meaning that headers wouldn't be extracted. This pull
request fixes that so that non-standard array types will return `true`
to allow extraction to happen.
## Reason for change
If we have valid headers we should extract them.
## Implementation details
Swapped to `GetEnumerator` as it seems more readable than the `foreach`
route.
If we have one value return `true` instead of `false`.
Swapped the `TryGetSingle` and `TryGetSingleRare` to `internal` to add
direct unit tests to them.
## Test coverage
- Added tests for `TryGetSingle` and `TryGetSingleRare` testing
fundamental behavior.
- Added tests for `Extract` to test possible behavior we could see.
## Other details
<!-- Fixes #{issue} -->
Fixes #6596
<!-- ⚠️ Note: where possible, please obtain 2 approvals prior to
merging. Unless CODEOWNERS specifies otherwise, for external teams it is
typically best to have one review from a team member, and one review
from apm-dotnet. Trivial changes do not require 2 reviews. -->
|
Hi @msciuto-photosi, I've just merged a fix for this, we have a release scheduled for next week that will include this, but this would be for the latest V3 as we haven't been backporting fixes to V2. If necessary, feel free to file a support ticket -> https://help.datadoghq.com/hc/en-us/requests/new?tf_1260824651490=pt_product_type:apm&tf_1900004146284=pt_apm_language:.net Thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tracer Version(s)
2.53.2
Operating system and platform
Linux x64
Instrumentation Mode
Manual with NuGet package
TFM
net8.0
Bug Report
Hi,
I am migrating a set of microservices (running on K8s) instrumented with Datadog.Trace.OpenTracing to OpenTelemetry. I noticed that the APM spans started from the "new" services using OpenTelemetry are not linked/propagated with the spans of the "old" services using OpenTracing, despite extracting the span context (they interact using HTTP calls) form the headers. Instead, if the calls are started from "old" microservices, the APM spans are linked with the "new" ones (and "old" ones, of course) since the span context is correctly propagated and extracted.
I checked the headers of requests and I can find the
traceparentheader for "old" and "new" microservices. The "old" ones also have thex-datadog-*family andtracestate.This is expected since there is no declaration of the environment variable
DD_TRACE_PROPAGATION_STYLEin the "old" microservices, hence the default value (datadog,tracecontext) is used, while the "new" ones use the grpc exporter to push data to the DataDog agent.So I dug into the code of this repository and I think that there is a bug in the
TryGetSingleRarefunction of theW3CTraceContextPropagatorclass, that is returning alwaysfalse(source). In my use case the flow reaches that point.Most likely the function should return
hasValue(instead offalse) after the foreach loop.We are using v2.53.2 of the tracer, but the bug is likely present in the v3.9.0 since that function has not changed.
Reproduction Code
No response
The text was updated successfully, but these errors were encountered: