Skip to content

flux-plunger suspension race can skip Helm uninstall #4060

Closed

Description

@myasnikovdaniil

What is wrong?

flux-plunger temporarily sets HelmRelease.spec.suspend=true while recovering release with has no deployed releases, deletes latest Helm storage Secret, sets reconcile annotation and then unsuspends release. It does not check deletionTimestamp before starting recovery, and error between updates can leave HelmRelease suspended.

When suspended HelmRelease is deleted, helm-controller v1.5.0 skips uninstall and removes its finalizer. HelmRelease disappears, but chart resources and Helm storage Secret remain.

For VMDisk this leaves DataVolume, PVCs, CDI importer pod, RBAC and WorkloadMonitor after both VMDisk and HelmRelease are deleted, but bug is not specific to VMDisk.

How to reproduce?

  1. Create VMDisk with import that stays in progress, for example HTTP source returning 404.
  2. Wait until DataVolume, importer and Helm release Secret exist.
  3. Set backing HelmRelease spec.suspend=true, reproducing state created by flux-plunger between its updates.
  4. Delete VMDisk through API.

HelmRelease disappears without UninstallSucceeded. DataVolume, PVCs, importer pod, RBAC, WorkloadMonitor and Helm release Secret remain without deletionTimestamp.

Control run with spec.suspend=false ends with UninstallSucceeded and removes all release resources.

How it should work?

Deleting HelmRelease must clean release resources even when flux-plunger recovery is running. flux-plunger should skip objects already being deleted and must clear suspension it owns after any failed step.

Delete can arrive after initial deletion check, so recovery needs sequence which guarantees Helm uninstall if deletion happens between suspend and unsuspend. Regression test should cover this exact window.

Activity

  1. added
    kind/bugCategorizes issue or PR as related to a bug
    area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)
    triage/acceptedIndicates an issue is ready to be actively worked on
    priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release
    and removed
    triage/needs-triageIndicates an issue needs triage by a maintainer
    on Sep 23, 2026
  2. added a commit that references this issue on Oct 12, 2026
    785cbc3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)kind/bugCategorizes issue or PR as related to a bugpriority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next releasetriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions