Introduction When a Helm upgrade fails, the release may be left in a "pending-upgrade" state, blocking all subsequent helm operations. This requires manual intervention to recover and either rollback or retry the upgrade.

Symptoms - `helm upgrade` fails with: "another operation is in progress" - `helm list` shows STATUS = pending-upgrade or failed - Subsequent helm commands return: "the object has been modified" - Resources partially updated (some old, some new) - Release history shows failed revision

Common Causes - Upgrade interrupted (network drop, timeout, user Ctrl+C) - Resource conflict: existing resource cannot be modified (immutable field changed) - Pre-upgrade hook failed - Insufficient permissions for the upgrade - Custom resource definition (CRD) version incompatibility

Step-by-Step Fix 1. **Check release status**: ```bash helm list --all --all-namespaces helm history <release-name> -n <namespace> ```

  1. 1.Rollback to previous revision:
  2. 2.```bash
  3. 3.helm rollback <release-name> <previous-revision> -n <namespace>
  4. 4.# Example: helm rollback my-app 3 -n production
  5. 5.`
  6. 6.Fix pending-upgrade state:
  7. 7.```bash
  8. 8.# Clear the pending state
  9. 9.kubectl patch secret <release-secret> -n <namespace> \
  10. 10.--type merge -p '{"metadata":{"labels":{"status":"deployed"}}}'
  11. 11.# Or force rollback
  12. 12.helm rollback <release-name> --force -n <namespace>
  13. 13.`
  14. 14.Check what changed that caused the failure:
  15. 15.```bash
  16. 16.helm upgrade <release-name> ./chart -n <namespace> --dry-run --debug
  17. 17.helm diff upgrade <release-name> ./chart -n <namespace>
  18. 18.`

Prevention - Use --timeout flag with appropriate values for your resources - Run `helm upgrade --dry-run` before actual upgrades - Use helm-diff plugin to preview changes - Avoid changing immutable fields (e.g., clusterIP, job selector) - Keep release backups: `helm get manifest <release> > backup.yaml`