How do you repair a Helm release whose stored manifest names a removed apiVersion, without deleting the running workload?

### The constraint The live objects are fine and must stay up — a fraud-scoring endpoint cannot take an outage to fix a bookkeeping problem. What is broken is Helm's own record: the manifest stored with the current revision names an `apiVersion` the cluster no longer serves, so Helm cannot build objects from it, and every `helm upgrade` and `helm rollback` aborts. Any repair therefore has to change what Helm holds, not what the cluster runs. ### Option 1 — rewrite the stored record in place The most surgical fix replaces the retired group/version string inside the stored manifest of the revisions Helm will actually read. The Helm project publishes a plugin for exactly this job, `mapkubeapis`, which walks a release's records and rewrites known retired APIs in place; check that the build you install supports your Helm major version, since Helm 4 rebuilt the plugin format (`plugin.yaml` now declares `apiVersion: v1`, a `type` and a `runtime`, and `helm plugin install --verify` defaults to true). Doing it by hand means fetching the `sh.helm.release.v1.<name>.v<rev>` Secret, decoding it, editing the manifest inside, and writing it back. It is entirely doable and entirely unforgiving — a botched record is worse than the error you started with, so snapshot the Secret first. Which revisions? At minimum the current one, because that is what the next upgrade reads. If you want rollback to remain usable you have to repair every revision you might roll back to, since rollback reads the target's manifest as well. **Keeps:** the workload, the full history, rollback targets, and the release's identity. **Costs:** the fiddliest procedure of the three, and it must be repeated per release. ### Option 2 — drop the history and re-adopt Helm will adopt a pre-existing object into a release when that object already carries the ownership metadata Helm writes: the label `app.kubernetes.io/managed-by: Helm` plus the annotations `meta.helm.sh/release-name` and `meta.helm.sh/release-namespace` matching the release you are installing. Objects installed by Helm in the first place already have all three. So: 1. delete the release's stored records (`sh.helm.release.v1.<name>.v*`); 2. run `helm upgrade --install <same name> -n <same namespace>` with a chart that renders supported API versions. Helm finds no history, treats it as a fresh install, discovers the objects already exist, checks their ownership metadata, and takes them over. Nothing restarts. Since Helm 3.17, `--take-ownership` extends this to objects whose ownership metadata does *not* match — useful when some resources were created outside the original release. **Keeps:** the workload and a clean, correct record going forward. **Costs:** the entire revision history and every rollback target; and because Helm now believes nothing existed before, anything the old release owned that the new chart no longer renders is silently orphaned rather than deleted. Inventory those before you delete the records. ### Option 3 — uninstall and reinstall Correct only when the workload can be recreated. `helm uninstall` deletes the objects; you take an outage and lose anything not backed by durable storage. `helm.sh/resource-policy: keep` on the pieces you cannot lose makes uninstall skip them — but then you are re-adopting those objects anyway on the way back in, which is option 2 with extra steps and a partial outage. ### The wrinkle when a controller owns the release If the chart version is pinned by a GitOps controller, the controller is going to re-run the failing upgrade on its interval and re-fail it, and it may fight your repair or reinstate the old pin. Suspend reconciliation for that release before you start, do the repair, then land the chart bump in Git so the controller's next run is the corrected one. Repairing the record while Git still pins the old chart just means the retired `apiVersion` is rendered straight back into the next revision. ### The pairing rule Whichever repair you pick, it fixes the past. The chart bump fixes the future. Ship both, verify with `helm get manifest <release> -n <ns>` that the current record no longer contains the retired group, and only then hand the release back to normal delivery.