Skip to content

Limit processing of large Baggage data#5672

Merged
marcotc merged 6 commits into
masterfrom
fix-baggage
May 6, 2026
Merged

Limit processing of large Baggage data#5672
marcotc merged 6 commits into
masterfrom
fix-baggage

Conversation

@marcotc

@marcotc marcotc commented May 4, 2026

Copy link
Copy Markdown
Member

What does this PR do?

Adds item-count (64) and byte-size (8192) limits when extracting W3C baggage headers.
There's no change in behavior for baggage headers under the limit.

Change log entry

Yes. Limit extracted baggage header parsing to 64 items and 8192 bytes.

Additional Notes:

Keeps Ruby 2.5 compatibility by using bounded split instead of block-form String#split.

How to test the change?

bundle exec rspec spec/datadog/tracing/distributed/baggage_spec.rb

@marcotc marcotc self-assigned this May 4, 2026
@dd-octo-sts dd-octo-sts Bot added the tracing label May 4, 2026
@dd-octo-sts

dd-octo-sts Bot commented May 4, 2026

Copy link
Copy Markdown
Contributor

Typing analysis

Note: Ignored files are excluded from the next sections.

steep:ignore comments

This PR introduces 1 steep:ignore comment, and clears 1 steep:ignore comment.

steep:ignore comments (+1-1)Introduced:
lib/datadog/tracing/distributed/baggage.rb:216
Cleared:
lib/datadog/tracing/distributed/baggage.rb:180

@datadog-prod-us1-3

datadog-prod-us1-3 Bot commented May 4, 2026

Copy link
Copy Markdown

Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
Patch Coverage: 100.00%
Overall Coverage: 97.21% (-0.01%)

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

@pr-commenter

pr-commenter Bot commented May 4, 2026

Copy link
Copy Markdown

Benchmarks

Benchmark execution time: 2026-05-05 23:10:00

Comparing candidate commit 805b8be in PR branch fix-baggage with baseline commit 483848f in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 45 metrics, 1 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 ----------------------------------'

@marcotc
marcotc marked this pull request as ready for review May 5, 2026 21:16
@marcotc
marcotc requested review from a team as code owners May 5, 2026 21:16
@marcotc
marcotc requested a review from vpellan May 5, 2026 21:16

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2c3f9d79ce

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread lib/datadog/tracing/distributed/baggage.rb Outdated

@ivoanjo ivoanjo 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.

👍 LGTM

Comment thread spec/datadog/tracing/distributed/baggage_spec.rb Outdated
Comment thread spec/datadog/tracing/distributed/baggage_spec.rb
@p-datadog

Copy link
Copy Markdown
Member

The byteslice(0, MAX+1) + chop choice for the truncation case is clean — chop walks back to the last valid character boundary, so 1, 2, or 3 trailing partial bytes get dropped in a single step. The simpler byteslice(0, MAX) would have left invalid bytes in some inputs.

A follow-up on the same UTF-8 dimension, after going through the rest of the parser. Two pre-existing raise paths still reach the caller of Propagation#extract, since propagate_baggage runs outside the rescue block at propagation.rb:146:

  1. UTF-8-tagged input with invalid byte sequences → String#split and String#strip raise ArgumentError: invalid byte sequence in UTF-8.
  2. Malformed percent-encoding (%XX, lone %) → URI.decode_www_form_component raises ArgumentError: invalid %-encoding.

Both pre-existing, not introduced here. Flagging because this PR is already focused on UTF-8 in this method, and the new byte cap creates a small envelope where a 9KB invalid-UTF-8 header gets handled cleanly via byteslice+chop+remove_last_entry → {}, while the same bytes in a 100-byte header still raise.

Opened #5689 as a self-contained companion fix to make the recommendation easy to evaluate alongside this PR. It adds a valid_encoding? guard at the top of parse_baggage_header and a rescue ArgumentError around the two URI.decode_www_form_component calls — both route into the existing malformed-telemetry path. ASCII-8BIT input (Rack's typical encoding) is unaffected. Three new specs lock the contract; two of them fail without the production change.

The two PRs touch parse_baggage_header at different lines and merge cleanly in either order — no dependency.

@marcotc
marcotc merged commit 3619470 into master May 6, 2026
416 checks passed
@marcotc
marcotc deleted the fix-baggage branch May 6, 2026 20:44
@dd-octo-sts dd-octo-sts Bot added this to the 2.32.0 milestone May 6, 2026
@marcotc marcotc mentioned this pull request May 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants