What Does This Do

• Adds void reportBlockFailure(); to AppSecContext (internal-api), alongside isManuallyKept().
• Implements reportBlockFailure() in AppSecRequestContext by delegating to the existing setWafRequestBlockFailure() volatile field — no new state added.
• Wires NettyMultipartHelper#tryBlock(): captures the boolean returned by BlockResponseFunction#tryCommitBlockingResponse(...); on false, resolves AppSecContext via ctx.getData(RequestContextSlot.APPSEC) (the canonical instanceof pattern already used by LambdaAppSecHandler) and calls reportBlockFailure(). The method still throws BlockingException unconditionally, unchanged.
• Makes NettyBlockResponseFunction#tryCommitBlockingResponse() idempotent per request: a single request can trigger multiple blocking evaluations (e.g. one tryBlock() call per multipart chunk in HttpPostRequestDecoderInstrumentation's advice). Once an earlier call has already committed the block successfully, ServerRequestContext.isPending() legitimately turns false for the request — without this guard, a later call would misread that as a commit failure and report a spurious block_failure for a block that actually succeeded.
• Fixes the async branch of tryCommitBlockingResponse() (event-loop execute() path): the blockingResponseInitiated idempotency flag is now only set inside the scheduled callback, after commitBlockingResponse(...) actually confirms success — not immediately after scheduling the task. Found by Datadog Autotest during review: the previous ordering silently hid any commit failure that happened inside the callback.
• Adds a one-line comment at MaybeBlockResponseHandler#write()'s writeAndFlush listener flagging the async post-commit write-failure path as a known, currently-unreported gap for a future framework PR to pick up.
• Adds test coverage:
  • A new case in WAFModuleSpecification.groovy asserting WafMetricCollector.raspRuleMatch(RuleType, boolean blocked) is called with the correct blocked value after RASP action processing.
  • NettyMultipartHelperBlockFailureTest.java (new JUnit 5 test) verifying reportBlockFailure() fires when tryCommitBlockingResponse returns false, and does NOT fire when it returns true.

Scope

This is the first PR of a per-framework rollout — only Netty is covered here. Other frameworks (Tomcat, Jetty, Vert.x, Undertow, Grizzly, Play, Akka-http, Ratpack, RESTEasy, Jersey, Liberty, Spring-webmvc, commons-fileupload, okhttp) are explicitly out of scope and will get their own follow-up PRs. The async post-commit write failure in MaybeBlockResponseHandler (channel write happens after the block decision, listener-driven) is also deliberately deferred — wiring it up requires investigating the ordering between span/request close and the channel listener to avoid introducing a race.

Motivation

appsec.waf.requests currently has no signal for when an AppSec block action was decided but its commit to the client actually failed (e.g. the response was already committed, or the channel write failed). This closes that gap for the synchronous Netty commit path, so failed block enforcement becomes visible in telemetry instead of silently looking like a successful block.

Additional Notes

Known, unaddressed gap (flagged by Codex during review, not fixed in this PR): NettyMultipartHelper's reportBlockFailure() call can race GatewayBridge.onRequestEnded's single wafRequest(...) telemetry emission. If multipart parsing resolves the commit outcome after the request has already ended (and the AppSec context closed), the failure report only mutates a field that is never read again — it is silently counted as a success. This is a distinct issue from the MaybeBlockResponseHandler async-write gap noted above, and applies to any future framework wiring of block_failure that can resolve asynchronously relative to request-end.

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

Jira ticket: APPSEC-62696

Note: Once your PR is ready to merge, add it to the merge queue by commenting /merge. /merge -c cancels the queue request. /merge -f --reason "reason" skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.