-
Notifications
You must be signed in to change notification settings - Fork 13
feat: ensure tracecontext headers take precedence over datadog (AIT-10281) #142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…n")->SECTION("W3C Phase 3 support - Preferring tracecontext") with the following test inputs and outputs: - INPUT: traceparent - INPUT: tracestate - INPUT: x-datadog-trace-id - INPUT: x-datadog-parent-id - INPUT: x-datadog-tags - OUTPUT: expected_parent_id - OUTPUT: expected_datadog_w3c_parent_id This tests the system-test case test_tracestate_w3c_p_extract_datadog_w3c for W3C Phase 3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If my understanding of the RFC is correct, the sole addition of phase 3 is:
MUST follow the rules below if
_dd.parent_id
tracestate if thep
value is not set
- Fallback 1: _dd.parent_id SHOULD be set using the parent_id extracted from datadog (x-datadog-parent-id). The value must be encoded according to W3C Phase 2 Plan
- Fallback 2: Do not set _dd.parent_id
In that case, your change is unnecessary and only this section of the code needs to be updated.
EDIT: I forgot that the parent id must come from x-datadog-parent-id
. Your change is still perfectible, when tracecontext
is the first extraction style, and p
is missing from the tracestate, then _dd.parent_id
will not be set.
Searching for attribute X for propagation style Y seems inevitable, may I suggest a bigger change? Instead of pushing all extracted data to a std::vector<ExtractedData>
here, use an std::unordered_map<PropagationStyle, ExtractedData>
.
Accessing an attributes for a given propagation style will be constant and improve the code readability. What do you think? :)
In the case where
Yes this seems like a good change, I will follow up with a change to do that 👍🏼 EDIT: updated in 1742ee9 |
…d the first_style to be used as the main context. This improves the lookup and logic of the merge at the cost of moving up the error cases up a level to Tracer::extract_span
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #142 +/- ##
==========================================
- Coverage 94.47% 94.46% -0.02%
==========================================
Files 73 73
Lines 3800 3811 +11
==========================================
+ Hits 3590 3600 +10
- Misses 210 211 +1 ☔ View full report in Codecov by Sentry. |
That's partially true. There's two contradictory fallbacks. I'll let @mabdinur decide but my understanding is: set If we agree on the same understanding, then:
|
Oh I think I understand where the confusion is, there's two different scenarios:
If |
I updated the design over to state: This design adds the following logic for trace context header extraction: When tracecontext and other supported distributed tracing headers contain identical trace_ids but conflicting parent_ids tracer libraries:
The W3C Phase 3 plan was supposed to be additive and suppliment the W3C Phase 2 doc. When writing the phase 3 plan I tried to omit details stated in Phase 2. I think this is the source of confusion. I updated the Phase 3 design overview to clearly state our end goals. |
I am still confused on the following case:
In this case, the RFC text says that we should use the x-datadog-parent-id value as the Last Datadog Parent Id ( |
We don't need to handle tracecontext,datadog. If the primary/first propagation style is tracecontext then we don't need to do any of the reparenting logic. In that scenario the span_id and trace_id from the tracecontext headers are used and datadog headers are ignored. I can reaword the spec to make this clear |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Once you've replace (*data).
for data->
, it's good to merge. Thanks for contributing.
Fixes field accesses from pointers Co-authored-by: Damien Mehala <damien.mehala@datadoghq.com>
Description
Adds support for "W3C Phase 3" so that when multiple trace contexts are extracted (with the same trace-id) and the
tracecontext
format is used, the resulting trace context will have:span.parent_id
set to thetracecontext
parent-id valuespan.tags["_dd.parent_id"]
set to either the value oftracestate[dd][p]
orhex(x-datadog-parent-id)
, in that order of precedence