GeneratingPolicy Downstream Cleanup#

GeneratingPolicy (the CEL-based successor to ClusterPolicy generate rules) has two known gaps vs. legacy ClusterPolicy when it comes to cleaning up downstream resources:

1. Webhook-level match condition evaluation: When a trigger UPDATE causes it to stop satisfying a GeneratingPolicy's matchConditions, no downstream cleanup UR is created — orphaning the previously generated resource. ClusterPolicy handles this via syncTriggerAction.
2. Background controller SyncWatchers scoping: SyncWatchers tracks generated resources at the policy+GVR level rather than per-trigger UID, causing cross-trigger data loss and per-resource orphaning.

Status (as of 2026-09-03):

• Bug #16832 1 has been closed by PR #16920 (merged 2026-09-03). The fix propagates the synchronize option to UpdateRequests and changes policy update handling from DeleteDownstreams to InvalidateDownstreams.
• Bug #16759 2 remains open.

Gap 1: No Webhook-Level Cleanup When Trigger Stops Matching#

ClusterPolicy behavior (working)#

In generation/handler.go, handleTrigger calls engine.ApplyBackgroundChecks on every admission event 3. Rules that fail (i.e., the resource no longer matches) are passed to syncTriggerAction. For each failed rule where rule.Generation.Synchronize == true, syncTriggerAction builds a UR with DeleteDownstream: true, queuing background deletion of the downstream.

GeneratingPolicy behavior (broken)#

gpol/handler.go's Generate runs entirely in a fire-and-forget goroutine 4. It does not call engine.ApplyBackgroundChecks or any equivalent CEL evaluation. Match filtering is performed upstream by the webhook routing layer — matchConstraints/matchConditions are applied on the ValidatingWebhookConfiguration and only already-matched policies are forwarded to this handler. The handler therefore never receives a "no longer matches" signal.

Consequence (issue #16832): When a namespace label is removed (or any trigger UPDATE causes matchConditions to evaluate to false), the gpol handler receives no request for that policy+trigger pair, creates no cleanup UR, and the downstream is orphaned indefinitely 1. The orphaned resource retains its ownership labels (generate.kyverno.io/policy-name, generate.kyverno.io/trigger-uid, etc.) but is never reclaimed.

No workaround via empty desired set: Returning [] from the CEL generate expression when the opt-in condition is absent also fails — the background controller does not delete existing downstreams when the desired set goes empty 1.

DeleteDownstream and Synchronize flags#

These flags are set in RuleContext by the webhook handler and consumed by ProcessUR in the background controller:

For trigger DELETE the handler works correctly: if the policy does not include DELETE in its ResourceRules, deleteDownstream is set to true and (when sync is enabled) the UR is created 7.

For trigger UPDATE that stops matching: no UR is created at all. This is the missing path.

Legacy GenerateController comparison#

GenerateController.applyGenerate checks ruleContext.DeleteDownstream or a nil policy first 8 and calls deleteDownstream. That function uses ur.Status.GeneratedResources if available, otherwise falls through to handleNonPolicyChanges which performs a label-based lookup via getDownstreams/fetch. The label query filters on generate.kyverno.io/trigger-uid with a name-based fallback for older resources 9.

Gap 2: SyncWatchers Per-Trigger Scoping Bug#

WatchManager.SyncWatchers is called in a goroutine after a successful generation pass when synchronize: true 10. The watcher tracks generated resources at policy+GVR granularity, not per-trigger UID.

Bug 1 — Cross-trigger deletion (#16759, 2): When Trigger A evaluates to 0 generated resources, SyncWatchers sees an empty list for that GVR, loops through its metadataCache matching GeneratePolicyLabel == policyName, and deletes all cached downstreams across all triggers for that policy — including Trigger B's downstream.

Bug 2 — Individual resource orphan 2: If a policy returns 2 ConfigMaps for a single trigger and later only 1, SyncWatchers sees the GVR is still present in newGVRs and skips the deletion loop entirely. The second ConfigMap is never removed.

Root cause: SyncWatchers does not scope its diff to generate.kyverno.io/trigger-uid. The fix requires the watcher's diff logic to use GenerateTriggerUIDLabel to scope additions/deletions to the trigger currently being evaluated.

Partial fix in PR #16920: When a policy is updated, downstream resources are now invalidated in the metadata cache (by setting Hash = "") instead of being deleted. The watcher's handleUpdate and handleDelete methods check for invalidated entries and skip restoration. This prevents stale downstream resources from being restored to a previous version when a policy update event is processed before SyncWatchers() completes. The synchronize option is now correctly propagated to UpdateRequests, ensuring the update/delete handling logic in generate_controller.go is invoked when appropriate.

Key Files#

Open Issues#