A helm upgrade fails partway through, and the next helm upgrade attempt fails with 'another operation is in progress.' What's happening and how do you recover?

Helm's release secret has a status field (deployed, pending-upgrade, pending-install, pending-rollback, failed, superseded). If a helm upgrade process is killed — a CI runner timing out, the Tiller-less Helm 3 client losing connectivity mid-operation, a node hosting a controller restarting — the release can be left with status=pending-upgrade indefinitely, since nothing else automatically clears it. Helm's own concurrency guard then refuses any new operation against that release with 'another operation is in progress. Try again later,' since a genuinely concurrent operation would corrupt the release history.

Recovery steps: first check helm status <release> and helm history <release> to see the current state and the last known-good revision. If you're confident nothing is actually still running (check for any lingering CI job or controller process that might still be mid-upgrade), the safe path is helm rollback <release> <last-good-revision>, which itself performs a normal Helm operation and clears the stuck status by creating a new, successful revision. If rollback itself refuses due to the lock, the more invasive but sometimes necessary step is directly editing the release Secret's status field (or deleting the specific stuck revision Secret, as a last resort, understanding this bypasses Helm's own history tracking) to unblock a fresh upgrade.

The cleaner long-term fix is running production upgrades with --atomic (and --cleanup-on-fail for installs), which tells Helm to automatically roll back on failure rather than leaving a half-applied, locked release behind in the first place.