Summary
Follow-up to #254 / #255. The TPP retrigger controller (internal/extensionserver/retrigger/tpp.go) forces Envoy Gateway to re-translate on a TrafficProtectionPolicy create or spec change, so mode/spec flips reach the edge promptly. Two related cases are not covered and can leave stale WAF config on the data plane:
1. TPP deletion
When a TPP is deleted, its governed Gateways are never nudged, so the edge keeps serving the last WAF program (e.g. an Enforce policy keeps blocking after the policy is gone) until an unrelated EG-watched resource incidentally re-translates.
Root cause: the controller's predicate drops deletes, and standard Reconcile receives only the object key — not the last-known object — so on delete there are no targetRefs to resolve owning Gateways from.
2. targetRef removal
On a targetRef edit, only the current targets are touched. A Gateway dropped from spec.targetRefs is not nudged, so it keeps the old WAF config even though the policy no longer governs it.
Impact
Same class of failure as #254 (stale WAF on the edge, no signal), narrower trigger: disabling protection by deleting a TPP (or removing a target) may not take effect for minutes-to-never in a quiet namespace. Enforce can keep blocking after a user removes the policy.
Fix direction
Track enough state to know the previous owning Gateway set, then touch the union of old and new targets:
- Use a mapping event handler (
Watches + handler.EnqueueRequestsFromMapFunc) that captures the deleted/old object's targetRefs, or
- Record last-applied targets (annotation on the TPP, or an in-memory map keyed by TPP) and diff on each reconcile, or
- A finalizer that fires the retrigger on deletion before the object is removed (heavier; TPPs are replicated edge objects).
On delete/removal, touch each previously-owning Gateway so EG re-translates and drops the now-orphaned WAF config.
Refs
Summary
Follow-up to #254 / #255. The TPP retrigger controller (
internal/extensionserver/retrigger/tpp.go) forces Envoy Gateway to re-translate on aTrafficProtectionPolicycreate or spec change, so mode/spec flips reach the edge promptly. Two related cases are not covered and can leave stale WAF config on the data plane:1. TPP deletion
When a TPP is deleted, its governed Gateways are never nudged, so the edge keeps serving the last WAF program (e.g. an
Enforcepolicy keeps blocking after the policy is gone) until an unrelated EG-watched resource incidentally re-translates.Root cause: the controller's predicate drops deletes, and standard
Reconcilereceives only the object key — not the last-known object — so on delete there are notargetRefsto resolve owning Gateways from.2. targetRef removal
On a targetRef edit, only the current targets are touched. A Gateway dropped from
spec.targetRefsis not nudged, so it keeps the old WAF config even though the policy no longer governs it.Impact
Same class of failure as #254 (stale WAF on the edge, no signal), narrower trigger: disabling protection by deleting a TPP (or removing a target) may not take effect for minutes-to-never in a quiet namespace. Enforce can keep blocking after a user removes the policy.
Fix direction
Track enough state to know the previous owning Gateway set, then touch the union of old and new targets:
Watches+handler.EnqueueRequestsFromMapFunc) that captures the deleted/old object'stargetRefs, orOn delete/removal, touch each previously-owning Gateway so EG re-translates and drops the now-orphaned WAF config.
Refs
internal/extensionserver/retrigger/tpp.go