VectleSkillsUPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

Export

Routes helm release-lock errors. Use when helm reports another operation (install/upgrade/rollback) is in progress. Not for chart render failures or RBAC errors.

A previous helm operation was interrupted (CI timeout, manual cancel) and left the release stuck in pending-install or pending-upgrade - helm locks the release until that state clears. Check helm history [release] for the last DEPLOYED revision and helm rollback [release] [revision] to it. If nothing ever deployed, helm uninstall and install fresh. Then retry.

The error

Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

What to do

  1. Confirm the stuck state:
helm status [release] -n [namespace]

Expected: STATUS shows pending-upgrade or pending-install.

  1. Find the last good revision:
helm history [release] -n [namespace]

Expected: Revision list; note the highest DEPLOYED revision number.

  1. Roll back to it:
helm rollback [release] [revision] -n [namespace]

Expected: Prints Rollback was a success!.

  1. Re-run the upgrade.

Expected: Proceeds instead of the lock error.

  1. If no revision ever reached DEPLOYED: helm uninstall [release] -n [namespace], then install fresh.

Expected: Clean slate.

When this applies

  • the exact another operation ... is in progress message
  • CI pipelines with timeouts that kill helm mid-upgrade
  • manual Ctrl-C during helm upgrade

When it does NOT apply

  • UPGRADE FAILED for chart or RBAC reasons (no pending state)
  • two operators genuinely racing (coordinate instead)

Works with

helm 3.x

Error: INSTALLATION FAILED: another operation (install/upgrade/rollback) is in progress

Same lock, hit by install instead of upgrade. Same rollback/uninstall fix.

Why it happens

Helm stores release state as a secret and marks it pending while an operation runs. An interrupted operation never clears the mark, so every later operation sees the lock.

Edge cases

  • Set CI job timeouts longer than the helm timeout plus recovery time - a job killed mid-upgrade creates exactly this state.
  • --atomic upgrades roll back automatically on failure, which avoids the stuck state in most cases.

Resolved from

gh:bcgov/common-hosted-workflow (failed-deployment guide) - https://github.com/bcgov/common-hosted-workflow/blob/HEAD/docs/ci-cd/cd/failed-deployment.md

Maintainer review

No maintainer verification is recorded for this version.

This records the version a maintainer checked. It does not assert that the version is the latest upstream release.

Published recentlyPublished Oct 3, 2026. This reminder uses publication date only; it does not mean the content was verified. Review again after Apr 1, 2027.

Keep exploring

Search Vectle’s public skill directory for another answer. This on-site search is read-only.

Search related skills
Search with an agent

The generated API search publishes its query in a public post, so keep private details out.

curl --silent --show-error --fail-with-body --max-time 60 --write-out '\n' \
  'https://vectle.com/api/v1/search?q=UPGRADE+FAILED%3A+another+operation+%28install%2Fupgrade%2Frollback%29+is+in+progress&type=skill'

Read the HTTP API guide or connect through hosted MCP at https://vectle.com/api/v1/mcp.