* fix: enable concurrent status computation to prevent multi-minute delays
Set StatusComputeWorkers=8 on DefaultStatusWatcher for Wait,
WaitWithJobs, and WatchUntilReady. This opts in to the async status
computation added in fluxcd/cli-utils#20, preventing the informer
notification pipeline from being blocked by slow API calls when many
resources are updated simultaneously.
Without this, status computation for resources like Deployments (which
require additional LIST ReplicaSets/Pods calls) runs serially inside
the informer, causing growing delays of 1-3+ minutes when upgrading
many resources at once (e.g., ~20 Deployments via Helm).
Signed-off-by: maplemiao <maplemiao@tencent.com>
* refactor(kube): expose StatusComputeWorkers as a WaitOption
Replace the package-level DefaultStatusComputeWorkers variable with a
WithStatusComputeWorkers WaitOption threaded through waitOptions into
the statusWaiter. This removes global mutable state from pkg/kube and
lets callers opt in explicitly.
SDK consumers (e.g. helm-controller) inherit the zero value, which
preserves the upstream cli-utils synchronous behavior and avoids an
unexpected fan-out of status-compute goroutines when many releases
reconcile concurrently. The Helm CLI continues to enable 8 workers by
default via a shared pkg/cmd/flags.go helper, so install/upgrade/
rollback/uninstall/test users still get the fix for multi-minute
informer stalls out of the box.
Signed-off-by: maplemiao <maplemiao@tencent.com>
* refactor(kube): clamp negative StatusComputeWorkers values to zero
Address review feedback: when a caller passes a negative value to
WithStatusComputeWorkers, coerce it to zero rather than propagating
it to the underlying cli-utils watcher, where the behavior is
undefined. Zero is the safe default and matches the SDK opt-in
contract.
Signed-off-by: maplemiao <maplemiao@tencent.com>
---------
Signed-off-by: maplemiao <maplemiao@tencent.com>
Signed-off-by: Maple Miao <maplemiao@yunzhanghu.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
The previous change suppressed ctx.Err() whenever there were no
resource-specific errors, which incorrectly swallowed context.Canceled
and other non-deadline errors signalling an external interruption.
Refine the condition: only suppress context.DeadlineExceeded when there
are no resource-specific errors (resources are Unknown/NotFound, meaning
the delete wait succeeded or resources were already gone). Any other
context error — including context.Canceled — is always propagated.
Signed-off-by: Terry Howe <terrylhowe@gmail.com>
During informer initialization there is a brief window where watched
resources appear as Unknown before their real statuses are delivered.
The statusObserver skips Unknown resources when waiting for deletion
(they may have been deleted before the watch started), but if *all*
resources are in that transient Unknown state the skipped-resource list
is empty. AggregateStatus on an empty slice returns the desired status,
causing cancel() to be called immediately — before any real status event
has arrived.
Guard against this by tracking the count of Unknown-skipped resources.
When every resource was Unknown-skipped and none have a definitive status
yet, defer the early-cancel decision until at least one resource reports
a real status. This preserves the correct behaviour for resources that
were genuinely deleted before the watch started (they eventually receive
a NotFound or stay Unknown, and the aggregate succeeds), while fixing
the race for resources that are transiently Unknown at startup.
Also tighten the ctx.Err() check in waitForDelete: only append a
deadline error when there are resource-specific errors to accompany it.
A timeout while all resources are Unknown or NotFound is not itself an
error — the resources are in an acceptable state for a delete wait.
Fixes: TestStatusWaitForDelete/error_when_not_all_objects_are_deleted
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>
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>
Zhaofeng Miao
Matthieu MOREL
George Jenkins
Austin Abro
Terry Howe
abhay1999
rohansood10
Matheus Pimenta
Evans Mungai
Mohsen Mottaghi
shuv0id
Benoit Tigeot
Benoit Tigeot