Summary
When investigating #13503 ("Delete=false not working for StatefulSets with volumeClaimTemplates"), I confirmed the sync-option check itself is correct: shouldBeDeleted / isPruningDisabled both honor a resource's own Prune=false,Delete=false annotation, whether or not it has a manifest of its own in git. That issue's most likely real explanation (matching the original reporter's own retraction) is a Kubernetes-level gotcha, not an Argo CD bug: StatefulSet.spec.volumeClaimTemplates copies labels/annotations onto its PVCs only once, at PVC creation time. If a user adds Prune=false,Delete=false to the StatefulSet manifest after the PVCs already exist, the live PVC never actually receives the annotation - Argo CD then correctly deletes a genuinely-unprotected resource, but from the user's point of view (looking at their current manifest) the deletion looks like a bug.
Proposal
This is a real UX gap even though it isn't a correctness bug: a resource that Argo CD only tracks via live-state instance-tracking (res.RequiresPruning, e.g. a StatefulSet-owned PVC with no manifest of its own in git) can be cascade-deleted completely silently when its live object carries no sync-option annotation, with nothing in the logs or Application events to help a user notice the annotation never actually applied. For a resource that does have its own manifest in git, this isn't an issue - its behavior was explicitly authored there.
I'd like to add a warning (log line + Application event, the same mechanisms Argo CD already uses for other deletion-related notices) specifically for this "stray resource, no protection annotation" case, so a user in this situation gets a visible signal instead of just a missing PVC. This does not change deletion behavior at all - a resource that's actually annotated Delete=false is still retained exactly as today; this only makes the no-annotation case observable.
I have a working implementation (controller/appcontroller.go + tests reproducing both the retained-with-annotation and the warns-without-annotation cases) ready to submit as a PR once this issue is approved, per CONTRIBUTING.md.
Summary
When investigating #13503 ("Delete=false not working for StatefulSets with volumeClaimTemplates"), I confirmed the sync-option check itself is correct:
shouldBeDeleted/isPruningDisabledboth honor a resource's ownPrune=false,Delete=falseannotation, whether or not it has a manifest of its own in git. That issue's most likely real explanation (matching the original reporter's own retraction) is a Kubernetes-level gotcha, not an Argo CD bug:StatefulSet.spec.volumeClaimTemplatescopies labels/annotations onto its PVCs only once, at PVC creation time. If a user addsPrune=false,Delete=falseto the StatefulSet manifest after the PVCs already exist, the live PVC never actually receives the annotation - Argo CD then correctly deletes a genuinely-unprotected resource, but from the user's point of view (looking at their current manifest) the deletion looks like a bug.Proposal
This is a real UX gap even though it isn't a correctness bug: a resource that Argo CD only tracks via live-state instance-tracking (
res.RequiresPruning, e.g. a StatefulSet-owned PVC with no manifest of its own in git) can be cascade-deleted completely silently when its live object carries no sync-option annotation, with nothing in the logs or Application events to help a user notice the annotation never actually applied. For a resource that does have its own manifest in git, this isn't an issue - its behavior was explicitly authored there.I'd like to add a warning (log line + Application event, the same mechanisms Argo CD already uses for other deletion-related notices) specifically for this "stray resource, no protection annotation" case, so a user in this situation gets a visible signal instead of just a missing PVC. This does not change deletion behavior at all - a resource that's actually annotated
Delete=falseis still retained exactly as today; this only makes the no-annotation case observable.I have a working implementation (controller/appcontroller.go + tests reproducing both the retained-with-annotation and the warns-without-annotation cases) ready to submit as a PR once this issue is approved, per CONTRIBUTING.md.