Repository navigation
perf(tracer): use lookbehind for JWT prefix in default query-string regex - #9405
Merged
Merged
Conversation
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (9405) and master. ✅ No regressions detected |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![datadog-official[bot]](https://avatars.githubusercontent.com/in/1358509?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
More details
The JWT lookbehind preserves delimiters and allows adjacent tokens to be redacted without re-emitting captured text. Runtime verification was limited to standalone .NET 8 checks because the required .NET 11 SDK was unavailable.
🤖 Bits Code Review · Commit e3ea59e
BenchmarksBenchmark execution time: 2026-10-15 13:13:42 Comparing candidate commit 4b3b947 in PR branch Found 0 performance improvements and 11 performance regressions! Performance is the same for 61 metrics, 0 unstable metrics, 76 known flaky benchmarks, 50 flaky benchmarks without significant changes.
|
anna-git
approved these changes
Oct 14, 2026
anna-git
left a comment
anna-git
left a comment
Contributor
There was a problem hiding this comment.
Nit, in the pr description it says "The lookbehind keeps the same left boundary.", it's the same boundary except for a lone % before the JWT, as v.3.55.0 also redacted that case.
andrewlock
approved these changes
Oct 15, 2026
…egex The consuming prefix group added in #9374 prevents .NET from skipping ahead to candidate match positions, making non-JWT query strings 2.5-5x slower. A zero-width lookbehind keeps the same left boundary, stays linear on the ReDoS inputs, and removes the need for the ${1} replacement and the isDefaultPattern plumbing.
e-n-0
force-pushed
the
flavien.darche/query-string-jwt-lookbehind
branch
from
October 15, 2026 11:48
ba51946 to
9679a63
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of changes
(?:(?<![\w-])|(?<=%[0-9a-f]{2}))ey[I-L]instead of the consuming group(^|[^\w%-]|%[0-9a-f]{2})ey[I-L]from perf(tracer): reduce query-string matching cost #9374.${1}<redacted>replacement and theisDefaultPattern/ObfuscationQueryStringRegexWasConfiguredplumbing are removed,since the default pattern no longer captures the delimiter.
Every pattern, default or custom, is replaced with
<redacted>again.DD_TRACE_OBFUSCATION_QUERY_STRING_REGEXPmoves to registry implementationK.Reason for change
The consuming group in #9374 stops .NET from skipping ahead to positions where a match can start,
so every query string without a JWT got slower.
Measured on .NET 10 with the tracer's regex options (µs per call):
?id=123&page=2Interpreted mode shows the same 2-3x gap for 3.55.1.
The lookbehind keeps the same left boundary as #9374, except that a lone
%before the JWT no longer blocks the match (3.55.0 redacted that case too).Other tracers stay on the capture-group form because Go and RE2/J have no lookbehind.
Implementation details
Because the lookbehind does not consume the delimiter, adjacent JWTs are now all redacted.
Before, a JWT whose delimiter had been eaten by the previous match was left in clear:
?q=eyJa.eyJb=eyJc.eyJd=eyJe.eyJf?q=<redacted>eyJc.eyJd=<redacted>?q=<redacted><redacted><redacted>?t=eyJa%3D.eyJb%3D%3DeyJc.eyJd?t=<redacted>eyJc.eyJd?t=<redacted><redacted>?x=%eyJa.eyJb?x=%<redacted>It also fixes the case where
DD_TRACE_OBFUSCATION_QUERY_STRING_REGEXPis set to the default text:3.55.1 dropped the delimiter there (
?jwt<redacted>).Test coverage
%eyJand padded adjacent-JWT cases.Other details
Registry implementation
KofDD_TRACE_OBFUSCATION_QUERY_STRING_REGEXPholds the new default.