The previous fix (increasing timeout / reducing deletion delay) did not
work because the flakiness is not a timing problem at all.
Root cause: fluxcd/cli-utils HasSynced() returns true after the initial
list item is *popped* from DeltaFIFO, which is before AddFunc delivers
the ResourceUpdateEvent to the collector. This creates a race where the
SyncEvent can arrive at the statusObserver *before* the pod's Current
status is recorded. When that happens:
- statusObserver sees pod as Unknown
- Unknown is skipped for WaitForDelete (by design, to handle resources
that were already deleted before watching started)
- AggregateStatus([], NotFoundStatus) == NotFoundStatus → cancel()
- The watch context is cancelled before DeleteFunc can fire
- Final check: pod still Current → error
The test intent is to verify that waitForDeleteCtx (not the cancelled
generalCtx) is selected. A non-existent resource satisfies this:
- With waitForDeleteCtx=Background(): informer syncs with empty list
→ Unknown → cancel → success ✓
- With generalCtx (cancelled, wrong): context immediately done
→ ctx.Err() appended → error returned ✓
Remove the goroutine-based deletion and the pod creation to eliminate
the race while preserving the context-selection assertion.
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
TestMethodContextOverridesGeneralContext/WaitForDelete used a 1s
timeout with a 500ms deletion delay, leaving only ~500ms for the
fake watcher to propagate the delete event. On loaded CI runners
this window is too tight and causes intermittent failures.
Increase the timeout to 5s and reduce the deletion delay to 100ms
so there is ample headroom. Apply the same deletion-delay reduction
to TestStatusWaitForDelete which shares the same pattern.
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
Remove pre-Go modules import path comments from pkg/kube test files
(ready_test.go, resource_test.go, statuswait_test.go) for consistency
with the rest of the package.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
Import path comments (e.g. `// import "helm.sh/helm/v4/pkg/kube"`) are
a pre-Go modules convention no longer needed in module-aware builds.
Some files in pkg/kube had these comments while others did not, causing
inconsistency that triggered downstream Kythe indexing errors.
Remove the import comments from all affected files to make the package
declaration consistent across the directory.
Fixes#31846
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: abhay1999 <abhaychaurasiya19@gmail.com>
The import comment in pkg/kube/statuswait.go still referenced
helm.sh/helm/v3/pkg/kube while all other files in the package
correctly reference helm.sh/helm/v4/pkg/kube. This mismatch
causes downstream processing errors (e.g. kythe) when vendoring
Helm.
Fixes#31846
Signed-off-by: rohansood10 <rohansood10@users.noreply.github.com>
Tests were failing for cli-utils watcher because upstream k8s made
changes that impacted cli-utils. In k8s WatchListClient is now
enabled by default. Fake clients used for testing don't know this
semantic. cli-utils leverages reflection in k8s to handle this.
The Helm tests didn't handle this well.
The tests are updated to use PrependReactor and PrependWatchReactor
in the same way that cli-utils does for testing. This works without
wrapping the client.
Signed-off-by: Matt Farina <matt.farina@suse.com>
add missing coverage for the positive case where cluster-scoped resources (like ClusterRole or Namespace) should work correctly
Signed-off-by: Mohsen Mottaghi <mohsenmottaghi@outlook.com>
Adding some tests for multi namespace deployment, simulate restrcited rbac access and mixed namespace scope and cluster scope resources
Signed-off-by: Mohsen Mottaghi <mohsenmottaghi@outlook.com>
Adds chart name to dependency logs, namespace to resource waiting logs,
and confirmation message when all resources are ready.
Addresses #31520
Signed-off-by: shuv0id <110290476+shuv0id@users.noreply.github.com>
While testing SDK features for v4. I was surprised with the error:
"reporter failed to start: event funnel closed: context deadline exceeded"
This occurs when no timeout is set:
```
upgradeClient := action.NewUpgrade(actionConfig)
upgradeClient.WaitStrategy = kube.StatusWatcherStrategy
// When Timeout is zero, the status wait uses a context with zero timeout which
// immediately expires causing "context deadline exceeded" errors.
upgradeClient.Timeout = 2 * time.Minute
```
With this patch it will work without specifying.
Signed-off-by: Benoit Tigeot <benoit.tigeot@lifen.fr>
> "reporter failed to start: event funnel closed: context deadline exceeded"
It happens when you forget to set a minimal timeout:
```go
upgradeClient := action.NewUpgrade(actionConfig)
upgradeClient.WaitStrategy = kube.StatusWatcherStrategy
// When Timeout is zero, the status wait uses a context with zero timeout which
// immediately expires causing "context deadline exceeded" errors.
upgradeClient.Timeout = 2 * time.Minute
```
Also maybe it might be worth documenting this more clearly. Initial [PR](https://github.com/helm/helm/pull/13604) say:
> I have not written any docs, I assume that can be done when we are closer to Helm 4, a lot of it is covered by linking to - https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md
Related:
- https://github.com/helm/helm/pull/31411#issuecomment-3443925663
Signed-off-by: Benoit Tigeot <benoit.tigeot@lifen.fr>
Terry Howe
Matthieu MOREL
George Jenkins
abhay1999
tsinglua
rohansood10
Matheus Pimenta
Austin Abro
Evans Mungai
Feruzjon Muyassarov
Matt Farina
Brenden Ehlers
Mohsen Mottaghi
Robert Sirchia
wangjingcun
Mads Jensen
Stephanie Hohenberg
shuv0id
Benoit Tigeot
Benoit Tigeot