#252 does not neutralize an already-persisted inverted TPP on the live coraza edge path
#252 (shipped in v0.23.12) sets Accepted=False/reason Invalid and is meant to skip attachment so an inverted-paranoia TrafficProtectionPolicy (blocking > detection) never reaches the data plane. On the real alice edge that guard does not hold: inverted policies that predate the #251 admission rule are still enforced by the datum-downstream-gateway coraza filter and 500 all traffic (CRS 901500 fail-closed).
Confirmed in prod (2026-07-13, VictoriaMetrics coraza_envoy_filter_request_total): kev-httpbin (~53k 500s/24h) and pcep-lol-hnqr6o (~17k/24h) were live-500'ing on benign traffic while carrying {detection:1, blocking:2}. The neutralization only "worked" in an earlier assessment because it was read off the disabled EnvoyPatchPolicy path — which is not the enforcement path on the edges.
Fix
Make the controller actually withhold an inverted policy from the edge data plane — skip emitting its coraza config into the downstream EnvoyProxy/extension-server path (not just set the status condition), so a grandfathered inverted policy is inert (benign traffic 200s) instead of 500'ing.
Test (carry from #272)
The neutralization e2e case authored for this — test/e2e-nonblocking/trafficprotectionpolicy-neutralize-inverted/ plus the test-e2e-nonblocking Makefile target — was split OUT of #272 (which is now enforcement-correctness only) because it belongs with this controller fix. It is preserved in commit 28a775e on branch test/mechanism-a-runtime-coverage.
The test injects a grandfathered inverted TPP by bypassing #251's CEL admission (JSON-patch the paranoiaLevels x-kubernetes-validations off the CRD, create {detection:1, blocking:2}, restore the rule), then asserts a benign GET / returns 200 (not 500). It fails today; it should land green with this fix and become part of the gating suite at that point.
Refs: #242, #251, #252, #272, datum-cloud/infra#3408.
#252 does not neutralize an already-persisted inverted TPP on the live coraza edge path
#252 (shipped in v0.23.12) sets
Accepted=False/reasonInvalidand is meant to skip attachment so an inverted-paranoiaTrafficProtectionPolicy(blocking > detection) never reaches the data plane. On the real alice edge that guard does not hold: inverted policies that predate the #251 admission rule are still enforced by thedatum-downstream-gatewaycoraza filter and 500 all traffic (CRS 901500 fail-closed).Confirmed in prod (2026-07-13, VictoriaMetrics
coraza_envoy_filter_request_total):kev-httpbin(~53k 500s/24h) andpcep-lol-hnqr6o(~17k/24h) were live-500'ing on benign traffic while carrying{detection:1, blocking:2}. The neutralization only "worked" in an earlier assessment because it was read off the disabledEnvoyPatchPolicypath — which is not the enforcement path on the edges.Fix
Make the controller actually withhold an inverted policy from the edge data plane — skip emitting its coraza config into the downstream
EnvoyProxy/extension-server path (not just set the status condition), so a grandfathered inverted policy is inert (benign traffic 200s) instead of 500'ing.Test (carry from #272)
The neutralization e2e case authored for this —
test/e2e-nonblocking/trafficprotectionpolicy-neutralize-inverted/plus thetest-e2e-nonblockingMakefile target — was split OUT of #272 (which is now enforcement-correctness only) because it belongs with this controller fix. It is preserved in commit28a775eon branchtest/mechanism-a-runtime-coverage.The test injects a grandfathered inverted TPP by bypassing #251's CEL admission (JSON-patch the
paranoiaLevelsx-kubernetes-validationsoff the CRD, create{detection:1, blocking:2}, restore the rule), then asserts a benignGET /returns 200 (not 500). It fails today; it should land green with this fix and become part of the gating suite at that point.Refs: #242, #251, #252, #272, datum-cloud/infra#3408.