fix(tracer): drop dd= list-entries over 256 bytes from incoming tracestate#4721
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files
🚀 New features to boost your workflow:
|
🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: 8326d73 | Docs | Datadog PR Page | Give us feedback! |
c349c8c to
2c953d3
Compare
2c953d3 to
42fb0c0
Compare
42fb0c0 to
678063c
Compare
b145180 to
c5e14f5
Compare
…state During extraction, parseTracestate drops any dd= list-entry whose length exceeds 256 bytes, mirroring the cap already enforced on inject. The entry is excluded from both the parsed fields and the propagating tag stored on the SpanContext. Other vendors' list-entries are preserved. Adds a tracestateDDMaxSize constant and switches the existing inject literal to reference it. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
c5e14f5 to
0b8c0c7
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0b8c0c71b3
ℹ️ 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".
bm1549
left a comment
There was a problem hiding this comment.
LGTM pending review from a dd-trace-go expert
…check Per W3C list-member syntax, optional whitespace is allowed around each list-entry. Without per-entry trim, an oversized entry like " dd=..." did not match the dd= prefix check, so the size cap was skipped and the entry was stored as a propagating tag. Trim each entry before the prefix and length check in both the parse loop and the cleanup-rebuild loop. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
BenchmarksBenchmark execution time: 2026-05-04 21:59:35 Comparing candidate commit 8326d73 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 206 metrics, 9 unstable metrics.
|
|
/remove |
|
View all feedbacks in Devflow UI.
|
86c0f03
into
main
…state (#4721) ### What does this PR do? During extraction, `parseTracestate` drops any `dd=` list-entry from the incoming tracestate header whose length exceeds 256 bytes, mirroring the cap already enforced on inject. The entry is excluded from both the parsed fields and the propagating tag stored on the SpanContext. Other vendors' list-entries are preserved. Also adds a `tracestateDDMaxSize` constant and switches the existing inject-side literal to reference it. This PR also modifies existing behavior: the prior loop iterated through every `dd=` list-entry it found (a quirk whose purpose wasn't clear), whereas now encountering an oversized `dd=` list-entry halts further parsing, so any later `dd=` list-entries are not considered. Multi-`dd=` headers are invalid per W3C anyway. ### Motivation Inject already caps the `dd=` list-entry; extract had no equivalent ceiling. Co-authored-by: brian.marks <[email protected]>
What does this PR do?
During extraction,
parseTracestatedrops anydd=list-entry from the incoming tracestate header whose length exceeds 256 bytes, mirroring the cap already enforced on inject. The entry is excluded from both the parsed fields and the propagating tag stored on the SpanContext. Other vendors' list-entries are preserved.Also adds a
tracestateDDMaxSizeconstant and switches the existing inject-side literal to reference it.This PR also modifies existing behavior: the prior loop iterated through every
dd=list-entry it found (a quirk whose purpose wasn't clear), whereas now encountering an oversizeddd=list-entry halts further parsing, so any laterdd=list-entries are not considered. Multi-dd=headers are invalid per W3C anyway.Motivation
Inject already caps the
dd=list-entry; extract had no equivalent ceiling.