Consult AppSec trace rate limiter only when the WAF requests trace retention

[claponcet]

What Does This Do

Consults the AppSec trace rate limiter only when a WAF result actually requests trace retention (resultWithData.keep), instead of on every WAF match.

• keep true and limiter allows: the trace is force-kept as before.
• keep true and limiter denies: setWafRateLimited() is set for non-RASP requests, as before.
• keep false: the limiter is neither consulted nor consumed.

Event and attribute reporting are untouched — they were already independent of throttling.

Motivation

Solves APPSEC-69576.

ddwaf_run returns DDWAF_MATCH when attributes, actions, or events are non-empty, and the fingerprint processors evaluate unconditionally on every request. So the WAF reports a match with no event on ordinary traffic, and the rate limiter token was consumed on essentially every request. On a busy JVM the per-second budget was exhausted by non-events, and a genuine attack later in the request reused the already-throttled verdict and lost its force-keep.

Additional Notes

The gate is keep rather than events: the limiter governs force-keep only, so a result that reports an event without requesting retention has nothing to throttle, and events are reported either way.

Also removes an else branch that logged "There is no active span available" when keep was false rather than when the span was actually missing.

Tests: the two keep: false scenarios in the rule-output matrix no longer expect the limiter to be consulted, plus a new scenario covering a throttled keep: true, event: true result. Attack-rule expectations are unchanged, since rules with no output block default to keeping the trace.

The new coverage extends the existing Spock spec instead of migrating it — the file is built entirely on Spock interaction cardinality, so migrating it would bury a small behaviour fix in an unreviewable diff. Worth a separate change.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: APPSEC-69576

[datadog-official]

🎯 Code Coverage (details)
• Patch Coverage: 83.33%
• Overall Coverage: 57.45% (-1.69%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b40f2e9 | Docs | View more details | Give us feedback!}

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.87 s	14.59 s	[+0.9%; +2.9%] (maybe worse)
startup:insecure-bank:tracing:Agent	13.68 s	13.70 s	[-1.0%; +0.7%] (no difference)
startup:petclinic:appsec:Agent	17.60 s	17.44 s	[+0.2%; +1.7%] (maybe worse)
startup:petclinic:iast:Agent	17.53 s	17.57 s	[-1.2%; +0.6%] (no difference)
startup:petclinic:profiling:Agent	17.09 s	17.44 s	[-3.2%; -0.9%] (maybe better)
startup:petclinic:sca:Agent	17.56 s	17.51 s	[-0.6%; +1.1%] (no difference)
startup:petclinic:tracing:Agent	16.63 s	16.24 s	[-1.9%; +6.7%] (no difference)

Commit: b40f2e93 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[claponcet]

@codex review

[claponcet]

@DataDog review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-14T13:06:54.179057Z	b40f2e9	Draft marked ready
🔒 Security Review	✅ Completed 2026-09-14T13:07:05.717504Z	b40f2e9	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: 945bcc47d8

ℹ️ 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".

[datadog-official]

More details

A WAF result with keep=false no longer uses a limiter token. A result with keep=true still keeps or rate-limits the trace as before.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit 945bcc4 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: 945bcc47d8

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[datadog-official]

More details

The limiter now runs only when a WAF result requests trace retention. Event reporting and results without trace retention keep their existing behavior.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Datadog Autotest · Commit b40f2e9 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest}

[jandro996]

Good job, this correctly stops the rate limiter from being consumed by non-event matches.

Not a blocker, the ticket also mentions only setting the rate_limited flag when an event was actually denied force-keep. Right now it's gated on keep alone, so a keep: true, event: false match that gets throttled would still set that flag. Could you take a look and see if that's worth addressing, or if it's fine to leave as is?

[claponcet]

@jandro996 my understanding is that this flag should be used with the same condition as the throttle, which is only gated on keep