configMapGenerator name-suffix hash not propagated into helmCharts resources when namespace: is set (regression since v5.8.0)

What happened

Setting a top-level namespace: in kustomization.yaml breaks name-reference rewriting for configMapGenerator when the reference lives inside a resource rendered by helmCharts:. The ConfigMap still gets its hash suffix. The Helm chart's own reference to that ConfigMap doesn't get updated to match. kustomize build succeeds with no warning, so the break only shows up later, at apply time, as a pod stuck in ContainerCreating.

Drop the namespace: line and both old and new kustomize render this correctly.

Minimal repro

.
├── kustomization.yaml
├── mapping.yaml
└── values.yaml

kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: otel-system

configMapGenerator:
  - name: statsd-mapping
    files:
      - mapping.yaml

helmCharts:
  - name: prometheus-statsd-exporter
    repo: https://prometheus-community.github.io/helm-charts
    version: "0.13.0"
    releaseName: statsd-exporter
    valuesFile: values.yaml

values.yaml:

statsd:
  mappingConfigMapName: statsd-mapping
  mappingConfigMapKey: mapping.yaml

mapping.yaml:

mappings: []

kustomize build --enable-helm .

Expected

kind: ConfigMap
metadata:
  name: statsd-mapping-99tbd7m5c6
---
# Deployment
      volumes:
      - configMap:
          name: statsd-mapping-99tbd7m5c6
        name: statsd-mapping-config

Actual (v5.8.0+)

kind: ConfigMap
metadata:
  name: statsd-mapping-99tbd7m5c6
---
      volumes:
      - configMap:
          name: statsd-mapping    # no ConfigMap by this name exists
        name: statsd-mapping-config

Warning  FailedMount  kubelet  MountVolume.SetUp failed for volume "statsd-mapping-config" : configmap "statsd-mapping" not found

Bisection

Held helm at v3.18.4, swapped only the kustomize binary:

Swapping helm instead (v3.18.4 vs v3.19.4, kustomize held fixed) makes no difference either way. This is a kustomize-only regression, not a helm version issue.

A workaround exists, but we can't use it

Setting namespace: on the individual helmCharts entry instead of the top level avoids the bug, on every kustomize version tested:

Once a top-level namespace: is present, adding a per-chart one on top of it doesn't help. We hit this through ArgoCD, which sets the namespace via a top-level field, either written directly in the manifest or through kustomize edit set namespace (which produces the same file). There's no way for us to avoid that field being set.

How this relates to #5566 / #5940

Different bug, likely the same cause. #5566 was about .Release.Namespace resolving to "default" inside Helm templates even though the rendered object's metadata.namespace was already correct. #5940 fixed that by having NamespaceTransformer skip Helm-rendered resources and passing --namespace straight to helm template instead. That PR shipped in v5.8.0, the exact version this regression starts at.

Our guess: the same pipeline change that made NamespaceTransformer skip Helm resources also changed how those resources get indexed for NameReferenceTransformer, and that's what breaks the ConfigMap reference. Haven't traced it to a specific line.

Versions

kustomize v5.8.1 (also reproduced on v5.8.0)
helm v3.19.4 (also reproduced on v3.18.4)
macOS arm64

Impact

Any kustomization with a top-level namespace:, a configMapGenerator or secretGenerator, and a helmCharts entry whose values reference that generated name directly will silently render a broken reference. Nothing errors at build time.

We found this because ArgoCD's repo-server bumped from kustomize 5.7.0 to 5.8.1, and a production prometheus-statsd-exporter deployment broke with no manifest change on our end.