I renamed an Argo CD application and it deleted everything it managed

In September, I renamed an Argo CD application which led to the deletion of all resources it managed within six minutes. Our deployment process involves an application of applications, with a parent Application overseeing a directory of child Application manifests, each representing a service. Automated sync and pruning were enabled on each child Application.

The child Applications contained the resources' finalizer, a directive copied from Argo's examples. This finalizer instructed that when the Application was deleted, all managed resources must be deleted first. We were in the process of setting up a second region, so I renamed the payments application to payments-eu1. This change, approved by two individuals, amounted to a single line in the manifest and a file name update.

From Kubernetes' perspective, there is no concept of renaming; a new object is created, and the old object is removed. The parent Application synced shortly after the change, generating the new Application and subsequently deleting the old one due to pruning being enabled and the old manifest absent in Git. The finalizer performed its intended function, causing Argo to delete every resource managed by the previous Application: the Deployment, Services, ConfigMaps, and autoscaler.

The pods terminated, and the new Application synced, recreating everything from the same manifests. This process took six minutes, including image pulls, readiness checks, and the autoscaler starting anew from its minimum.

The only entities that survived were the database volumes, as claims created from StatefulSet templates were never tracked in Git and had not been managed by Argo. The diff provided an accurate account of the deletion, but it did not explicitly state it, as the deletion was governed by a finalizer on a different object, not within the change itself.

Child Application manifests now include the Prune=false sync option, preventing the parent from inadvertently deleting an application when its file disappears. Instead, it marks the application as out of sync and waits for human intervention.

Resources designated for the front door and stateful services carry Delete=false, ensuring that even a cascade deletion does not remove them from their designated locations. Renaming follows a documented procedure: create the new Application, remove the finalizer from the old Application, allow the new Application to adopt the resources, and only then delete the old manifest.

Additionally, a comment is included in pull requests that remove or rename Application files, requiring approval from the platform team before execution.

In a GitOps repository, a file name is not merely a label; removing a file is an explicit instruction, and the system executes it with the same rigor that was applied during its creation.