What does Helm's "another operation (install/upgrade/rollback) is in progress" error mean?

## What the message actually reports `Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress` is Helm telling you what it read out of the cluster, not what it observed happening. Helm has no server-side component: the CLI is the only actor, and everything it knows about a release it learns by reading that release's stored revisions back out of the namespace. Before it begins any write, it fetches the newest revision for the release name and looks at that revision's status. If the status is `pending-install`, `pending-upgrade` or `pending-rollback`, Helm stops immediately with this message. That check is *pessimistic* in the literal sense: it assumes a pending record means somebody else is mid-flight, and it errs on the side of refusing. It is not a lease, it has no expiry, and nothing sweeps it. A release can sit behind this error for months. ## Why a release ends up pending Every mutating Helm operation is a three-step dance: 1. Write a new revision record with a pending status (`pending-install` for revision 1 of an install, `pending-upgrade` for an upgrade, `pending-rollback` for a rollback). 2. Send the resources to the API server, and — depending on the wait strategy in use — watch them. 3. Rewrite that same revision as `deployed`, or as `failed` if the apply or the wait went wrong. Steps 1 and 3 are both performed by the same client process. If that process disappears between them, nobody ever performs step 3, and the record is frozen mid-transaction. The realistic causes are all mundane: - a CI job cancelled by a human, or killed when the pipeline hit its own wall-clock budget; - the pod or VM running the job evicted, pre-empted or scaled away; - an engineer pressing Ctrl-C, or a laptop losing its VPN or going to sleep; - the API server becoming unreachable partway through. The discriminator worth memorising: **Helm's own `--timeout` expiring does not strand a release.** When the wait times out, the client is still alive, so it completes step 3 and writes `failed`. A release you find in `failed` had a bad outcome; a release you find in `pending-*` had *no* outcome, because nothing was there to record one. That distinction drives everything you do next, because `failed` is a perfectly upgradeable state and `pending-*` is not. There is one genuine case where the message is honest — two pipelines really are upgrading the same release into the same namespace at the same time. The loser sees exactly this error. It is worth ruling out before you go clearing records, because clearing a record while another client is still working means two writers with two different ideas of the current revision. ## Confirming it before you act ``` helm status billing-cron -n billing helm history billing-cron -n billing ``` `helm status` prints the release's current status and the revision it belongs to; `helm history` prints one row per revision with its status, so you can see the pending row sitting on top of an older `deployed` row. The age of the pending revision is the tell: if it was written eleven minutes ago and your pipeline still shows a running job, wait. If it was written yesterday and no job exists, nothing is coming to finish it. ## What does not work - **Re-running the same `helm upgrade`.** The guard is state, not contention; the second attempt reads the same pending record and refuses identically. - **Waiting.** There is no TTL and no reaper. - **Adding `--force-replace`, `--force-conflicts` or a longer `--timeout`.** None of them is consulted; the check runs before any of that matters. - **Upgrading from a different machine or a different CI runner.** The state lives in the cluster, not on your workstation, so every client sees it. Recovery is a deliberate, separate act: roll back to the last revision that reached `deployed`, or — for a release that never had one — uninstall and install again, and only as the last rung remove the pending revision record itself. ## The mental model Treat the pending status as an uncommitted transaction with no rollback journal. Helm opened it, the process holding it died, and Helm is conservative enough not to guess whether the work was half-done. Everything you know about the cluster's *actual* state at that moment has to come from looking at the objects, because the release record has stopped being a description of reality and is now just a stuck flag. Helm 4 changed nothing here: it added no command that recovers a stuck release, and the guard behaves exactly as it did in Helm 3.