feat(tracing): add DD_TRACE_PROPAGATION_EXTRACT_FIRST - #356
Conversation
BenchmarksBenchmark execution time: 2026-08-26 13:10:45 Comparing candidate commit 984a97f in PR branch Found 2 performance improvements and 3 performance regressions! Performance is the same for 3 metrics, 0 unstable metrics.
|
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f8c667bb5
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (propagation_extract_first_ && extracted_trace_context) { | ||
| break; |
There was a problem hiding this comment.
Validate context before stopping extraction
When DD_TRACE_PROPAGATION_EXTRACT_FIRST=true, an earlier style can return a trace ID without a usable parent ID or origin—for example, incomplete Datadog headers followed by a complete matching W3C traceparent. This condition stops immediately because it checks only trace_id, after which the validation below returns MISSING_PARENT_SPAN_ID instead of allowing the later style to supply a valid context. Stop only after the extracted context meets the validity requirements used below; otherwise continue trying configured styles.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Indeed, we can see line 375 a test about parent_id.
I think we should clarify what is a successful extraction (and I suppose this would deserve a dedicated unit test).
Once again, I would really like to clarify the purpose of this block of code. I would start by extracting lines 277-343, but that's only a suggestion after a quick analysis, to be challenged.
|
For the record: DD_TRACE_PROPAGATION_EXTRACT_FIRST in Feature Parity Dashboard. |
xlamorlette-datadog
left a comment
There was a problem hiding this comment.
I find the C++ Tracer code difficult to reason because it is not in a very good state: it contains lot of legacy code, with questionable technical choices (but, unfortunately, many are part of the public interface).
From now on, I think we should try to clean the existing code to avoid deteriorating the situation further.
Especially here: Tracer::extract_span() is the biggest function: 273 lines!
Please, I think we should refactor this function (in a dedicated PR) before adding complexity to it.
| {extracted_tag}); | ||
|
|
||
| if (!first_style_with_trace_id && data->trace_id.has_value()) { | ||
| const bool extracted_trace_context = data->trace_id.has_value(); |
There was a problem hiding this comment.
I think the extracted_trace_context name is misleading:
- It makes me think this variable is a trace context.
- This only checks that a trace id was extracted, not a full context, which, I think, relates to the comment from Codex below.
Actually, because the existing code is not clean, I find it very difficult to reason about this:
- The
dataname does not convey any useful meaning. - The on-going modification is only about a part of the huge (270 lines!)
Tracer::extract_span()function.
I suggest adding a dedicated refactoring PR before this one to clean the Tracer::extract_span() function:
- At least extract the part to be modified, to clarify its purpose, and improve variable names. This could also allow to unit test easier the new behavior.
- Ideally, split the function in big blocks (skimming the function, it seems to me there are at least 4 different blocks).
| if (propagation_extract_first_ && extracted_trace_context) { | ||
| break; |
There was a problem hiding this comment.
Indeed, we can see line 375 a test about parent_id.
I think we should clarify what is a successful extraction (and I suppose this would deserve a dedicated unit test).
Once again, I would really like to clarify the purpose of this block of code. I would start by extracting lines 277-343, but that's only a suggestion after a quick analysis, to be challenged.
| std::vector<PropagationStyle> injection_styles; | ||
| std::unordered_map<std::string, std::string> extracted_headers; | ||
| std::unordered_map<std::string, std::string> expected_injected_headers; | ||
| bool extract_first = false; |
There was a problem hiding this comment.
This should be added in the capture block (lines 2121-2126).
Description
Adds C++ support for
DD_TRACE_PROPAGATION_EXTRACT_FIRST.Existing documentation for the configuration : DD_TRACE_PROPAGATION_EXTRACT_FIRST in Feature Parity Dashboard
Motivation
Allow extraction to stop after the first successfully extracted trace context, matching the shared tracer configuration.
Additional Notes
Priority: low
supported-configurations.jsonwithconfig-inversion.Jira ticket: N/A