Skip to content

fix: check for resource existence before scheduling deletion#32216

Open
szubersk wants to merge 1 commit into
helm:mainfrom
szubersk:fix/wait
Open

fix: check for resource existence before scheduling deletion#32216
szubersk wants to merge 1 commit into
helm:mainfrom
szubersk:fix/wait

Conversation

@szubersk

@szubersk szubersk commented Jun 15, 2026

Copy link
Copy Markdown

What this PR does / why we need it:
After upgrading from Helm v4.2.0 to v4.2.1, any helm upgrade --install --wait that deletes a resource and waits for it to be gone sits there for the entire --timeout instead of returning as soon as the resource is actually deleted.

closes: #32214

Special notes for your reviewer:

If applicable:

  • this PR contains user facing changes (the docs needed label should be applied if so)
  • this PR contains unit tests
  • this PR has been tested for backwards compatibility

Copilot AI review requested due to automatic review settings June 15, 2026 12:43
@pull-request-size pull-request-size Bot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Jun 15, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a pre-check in waitForDelete to treat already-deleted Kubernetes resources as a no-op instead of attempting to watch them.

Changes:

  • Import k8s.io/apimachinery/pkg/api/errors to detect NotFound errors.
  • Skip resources in waitForDelete when Get() returns NotFound, with a debug log.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread pkg/kube/statuswait.go Outdated
@benoittgt

Copy link
Copy Markdown
Contributor

Thanks @szubersk

We're gonna need some test to validate that it is fixing the issue.

@szubersk

Copy link
Copy Markdown
Author

We're gonna need some test to validate that it is fixing the issue.

It does - tested in my cluster. Unit-level testing seems too low-level for this kind of problem; I wonder if you guys considered adding integration-level tests (e.g., helm binary against a real k3s cluster).

thc1006 added a commit to thc1006/helm that referenced this pull request Jun 24, 2026
WaitForDelete treated a resource as already gone whenever the kstatus
watcher reported it as Unknown. But the watcher reports Unknown in two
cases: a resource that is genuinely gone, which never emits a delete
event, and a resource that still exists but whose status has not synced
yet. Treating both as deleted let the watch cancel before any real
status arrived, which is the TestStatusWaitForDelete flake in helm#32261.

The earlier fix for that flake (helm#32081) deferred that decision, which
made already-gone resources wait the full timeout (the hang in helm#32214).
It was reverted in v4.2.2, so the flake returned.

Check the cluster directly instead. Before watching, a resource that
returns NotFound from a live GET is already gone and is skipped, and the
observer no longer treats an Unknown status as deleted. Already-gone and
never-created resources, such as before-hook-creation hooks, return
immediately, while a resource that still exists is waited on until it is
actually deleted or the timeout is reached.

closes helm#32261
refs helm#32214
refs helm#32216

Signed-off-by: thc1006 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

--wait hangs for the full timeout on fast resource deletions in v4.2.1 (regression from v4.2.0)

3 participants