Skip to content

fix(tracer): use configurable MaxTagsHeaderLen for x-datadog-tags extraction#4727

Merged
mtoffl01 merged 3 commits into
mainfrom
mtoff/x-datadog-tags-extract-config
May 7, 2026
Merged

fix(tracer): use configurable MaxTagsHeaderLen for x-datadog-tags extraction#4727
mtoffl01 merged 3 commits into
mainfrom
mtoff/x-datadog-tags-extract-config

Conversation

@mtoffl01

@mtoffl01 mtoffl01 commented May 5, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

What does this PR do?

unmarshalPropagatingTags (the extract path for the x-datadog-tags header) now uses the configured MaxTagsHeaderLen as the size cap instead of a hardcoded 512-byte constant. A non-positive MaxTagsHeaderLen disables extraction, mirroring the existing inject-side disable behavior. The DD_TRACE_X_DATADOG_TAGS_MAX_LENGTH environment variable now governs both inject and extract.

Motivation

The env var was previously respected only on inject; extract used a hardcoded 512-byte cap regardless of the configured value. This brings the two directions into alignment.

@datadog-datadog-prod-us1

datadog-datadog-prod-us1 Bot commented May 5, 2026 •
edited by datadog-datadog-prod-us1-2 Bot
Loading

Copy link
Copy Markdown

Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 61.42% (+4.07%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: aeda5a9 | Docs | Datadog PR Page | Give us feedback!

@pr-commenter

pr-commenter Bot commented May 5, 2026 •
edited
Loading

Copy link
Copy Markdown

Benchmarks

Benchmark execution time: 2026-05-05 20:12:41

Comparing candidate commit aeda5a9 in PR branch mtoff/x-datadog-tags-extract-config with baseline commit c3b9324 in branch mtoff/config-migrate-max-tags-header-len.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 138 metrics, 9 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

@mtoffl01
mtoffl01 force-pushed the mtoff/x-datadog-tags-extract-config branch from 883c8a8 to 512397e Compare May 5, 2026 18:39
@mtoffl01
mtoffl01 changed the base branch from main to mtoff/config-migrate-max-tags-header-len May 5, 2026 18:39
@codecov

codecov Bot commented May 5, 2026 •
edited
Loading

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 62.03%. Comparing base (e1ddf38) to head (404de05).

Additional details and impacted files
Files with missing lines Coverage Δ
ddtrace/tracer/textmap.go 84.40% <100.00%> (+0.03%) ⬆️

... and 15 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@mtoffl01
mtoffl01 force-pushed the mtoff/config-migrate-max-tags-header-len branch from ad4f91f to e1ddf38 Compare May 5, 2026 18:46
@mtoffl01
mtoffl01 force-pushed the mtoff/x-datadog-tags-extract-config branch from 512397e to 404de05 Compare May 5, 2026 18:47
@mtoffl01 @claude
refactor(config): migrate maxTagsHeaderLen
ae4e8d7 
- Adds a public `Config.MaxTagsHeaderLen()` getter on
  `internal/config.Config`.
- Initialises the field in `loadConfig` from
  `DD_TRACE_X_DATADOG_TAGS_MAX_LENGTH`, preserving the existing clamping
  semantics (negative -> 0; > MaxPropagatedTagsLength -> clamped down).
- Adds `DefaultMaxTagsHeaderLen` and `MaxPropagatedTagsLength` exported
  constants in `internal/config`.
- Removes the duplicate env resolution from `tracer/option.go` and the
  `defaultMaxTagsHeaderLen` / `maxPropagatedTagsLength` constants there.
- The propagator is now constructed using
  `c.internalConfig.MaxTagsHeaderLen()` instead of locally re-reading the
  env var.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
@mtoffl01
mtoffl01 force-pushed the mtoff/config-migrate-max-tags-header-len branch from e1ddf38 to ae4e8d7 Compare May 5, 2026 19:30
@mtoffl01
mtoffl01 force-pushed the mtoff/x-datadog-tags-extract-config branch from 404de05 to 6bee9e8 Compare May 5, 2026 19:30
mtoffl01 and others added 2 commits May 5, 2026 15:36
@mtoffl01
nits
c3b9324
@mtoffl01 @claude
fix(tracer): use configurable MaxTagsHeaderLen for x-datadog-tags ext…
aeda5a9 
…raction

unmarshalPropagatingTags now uses the configured PropagatorConfig
MaxTagsHeaderLen as the size cap on incoming x-datadog-tags headers
instead of a hardcoded 512-byte constant. A non-positive MaxTagsHeaderLen
disables extraction, mirroring the existing inject-side disable behavior.
The DD_TRACE_X_DATADOG_TAGS_MAX_LENGTH environment variable now governs
both inject and extract.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
@mtoffl01
mtoffl01 force-pushed the mtoff/x-datadog-tags-extract-config branch from 36684ad to aeda5a9 Compare May 5, 2026 19:36
@mtoffl01
mtoffl01 marked this pull request as ready for review May 5, 2026 20:18
@mtoffl01
mtoffl01 requested review from a team as code owners May 5, 2026 20:18
darccio
darccio approved these changes May 6, 2026
View reviewed changes

@darccio darccio left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Base automatically changed from mtoff/config-migrate-max-tags-header-len to main May 7, 2026 14:46
@mtoffl01
mtoffl01 requested a review from a team as a code owner May 7, 2026 14:46
@mtoffl01
mtoffl01 merged commit adf1047 into main May 7, 2026
217 of 218 checks passed
@mtoffl01
mtoffl01 deleted the mtoff/x-datadog-tags-extract-config branch May 7, 2026 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@darccio darccio darccio approved these changes
@genesor genesor genesor approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@mtoffl01 @darccio @genesor