Helm doesn't wait for Custom Resources on new releases using `upgrade --install`.

What happened?

On Helm 4, I am seeing inconsistent wait behavior for a CR, specifically a Knative Service (serving.knative.dev/v1, Kind=Service) but I think this extends to other CRs.

When I run:

helm install ... --wait

Helm waits correctly until the resource becomes ready (Knative Service triggers the creation of some Pods, and Helm won't return till the Pods are actually ready).

When I run:

helm upgrade --install ... --wait

and the release does not yet exist, Helm reports that it is installing, but it returns before the Knative Service is actually ready. In debug logs the resource is briefly shown as actualStatus=Unknown, and Helm still finishes successfully shortly after.

level=DEBUG msg="waiting for resources" count=3 timeout=5m0s
level=DEBUG msg="waiting for resource" namespace=ml-platform name=paella-v1-6 kind=Service expectedStatus=Current actualStatus=Unknown
level=DEBUG msg="waiting for resource" namespace=ml-platform name=paella-v1-6 kind=Service expectedStatus=Current actualStatus=Unknown
level=DEBUG msg="all resources achieved desired status" desiredStatus=Current resourceCount=3

So the behavior seems different between install and upgrade --install.

Additionally, if the release already exists, running:

helm upgrade --install ... --wait

does wait correctly for the resources created by the Knative Service to become ready. This suggests the issue only occurs when upgrade --install performs a fresh install (i.e. when the release does not yet exist).

What did you expect to happen?

When using helm upgrade --install --wait and the release does not exist, I expect Helm to behave the same as helm install --wait. In particular, Helm should not complete successfully until all resources, including custom resources such as serving.knative.dev/v1 Service, have reached their desired ready/current state.

If a resource is still in an intermediate state (e.g. Unknown), Helm should continue waiting until it transitions to a stable ready state or the timeout is reached.

How can we reproduce it (as minimally and precisely as possible)?

With Knative installed on the cluster, is enough to deploy a resource like this one within a Chart.

kind: Service
metadata:
  name: hello-knative
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "World"
          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
            successThreshold: 5

This manifest has long readiness on purpose, Helm won't wait for its readiness on new installation with upgrade --install.

Helm version

version.BuildInfo{Version:"v4.1.4", GitCommit:"05fa37973dc9e42b76e1d2883494c87174b6074f", GitTreeState:"clean", GoVersion:"go1.25.9", KubeClientVersion:"v1.35"}

Kubernetes version

Client Version: v1.31.2
Kustomize Version: v5.4.2
Server Version: v1.34.4-eks-f69f56f
WARNING: version difference between client (1.31) and server (1.34) exceeds the supported minor version skew of +/-1