What do Helm's pending-install, pending-upgrade and pending-rollback release statuses mean?

## Every revision carries a status A Helm release is a numbered sequence of revisions, and each revision stores a status. The statuses split into two groups. The terminal ones describe an outcome: `deployed` (this revision is the live one), `failed` (this revision's operation reached a verdict and it was bad), `superseded` (this revision was the live one until a newer revision took over), `uninstalled` (the release was removed but its history was kept). Two more describe motion: `uninstalling`, on the delete path, and the three pending values, on the write path. The pending values are one per mutating operation: - **`pending-install`** — written on revision 1 when `helm install` begins. It is the only pending status that can appear on a release with no earlier revision, and that matters later, because there is nothing behind it to go back to. - **`pending-upgrade`** — written on the new revision that `helm upgrade` creates. The previous revision is still sitting there as `deployed` while this one is in flight. - **`pending-rollback`** — written on the new revision that `helm rollback` creates. A rollback does not rewind history; it appends a revision whose content is copied from an older one, and that new revision goes through the same pending-then-terminal cycle. ## Why the pending write exists at all Helm records its intent before it acts. The sequence for an upgrade is: create the new revision as `pending-upgrade`, send the rendered resources to the API server, wait according to the wait strategy in force, then rewrite that same revision as `deployed` on success or `failed` on error. Writing the record first is what makes the state recoverable at all — if Helm applied first and recorded afterwards, an interrupted run would leave objects in the cluster that no release knows about. The consequence is the thing interviewers are really testing: because the status is written by the client and cleared by the same client, a pending status is only accurate while that client lives. Any pending status you find at rest means the process died mid-operation — a cancelled pipeline, an evicted runner, a closed laptop — and nothing will ever come back to finish the write. Helm's next mutating command reads that status and refuses with `another operation (install/upgrade/rollback) is in progress`. Note what a pending status is *not*. It is not the same as `failed`. A run that errored, or whose wait exceeded `--timeout`, still had a live client to write the verdict, so it lands in `failed` — and `failed` is an ordinary state you can upgrade or roll back straight out of. Pending means no verdict was ever recorded, which is why it blocks. ## Seeing them ``` helm status billing-cron -n billing helm list --pending -n billing helm history billing-cron -n billing ``` `helm status` reports one named release and prints its current status. `helm list` shows the releases in a namespace, one row each, with a STATUS column; the status flags such as `--pending`, `--failed` and `--deployed` narrow that listing. `helm history` is the per-release view: one row per revision, so you can see a `pending-upgrade` row 31 sitting on top of a `deployed` row 30 and know exactly which revision is stuck and which one is still live. There is a version trap here worth knowing. In Helm 3, `helm list` showed only a default subset of statuses and the idiomatic way to see everything, pending releases included, was `helm list -a` (or `--all`). **Helm 4 removed `-a`/`--all` entirely**: `helm list` now shows every status by default and the status flags only narrow the result. The unrelated `-A`/`--all-namespaces` flag is still there and still means something completely different — search every namespace rather than every status. A candidate who reaches for `helm list -a` on a Helm 4 CLI gets an unknown flag error, so it is worth having both behaviours in your head while both major versions are in the field. ## Reading the pair of rows The most useful skill is reading `helm history` as a two-line story. Revision 30 `deployed`, revision 31 `pending-upgrade` means: 30 is still the last revision Helm considers good, 31 was started and abandoned, and whatever 31 managed to push into the cluster before it died is now live but unrecorded as such. Revision 1 `pending-install` alone means: the install never completed, there is no good revision at all, and rolling back is not an option because there is nothing behind it. Those two shapes call for different recoveries, and identifying which one you have is the whole first step.