configMapGenerator unable to replace/merger ConfigMap from a Helm chart

[velp]

What happened?

Kustomize is unable to replace/merge the contents of a ConfigMap if the ConfigMap comes from the Helm generator.

What did you expect to happen?

Kustomize should be able to replace/merge the content of any ConfigMaps regardless if they are local or from the chart.

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

Both options bellow reproducing the problem. Tested behavior:replace, merge.

Option 1:
File kustomization.yaml

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

helmCharts:
- name: vault
  namespace: vault
  releaseName: vault
  repo: https://helm.releases.hashicorp.com
  version: 0.22.0

configMapGenerator:
- behavior: replace
  literals:
  - thing=stuff
  name: vault-config
  namespace: vault
  options:
    disableNameSuffixHash: true

Option 2:
This option was described here: #4799 (comment) but it's not working.

File kustomization.yaml:

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

helmCharts:
- name: vault
  namespace: vault
  releaseName: vault
  repo: https://helm.releases.hashicorp.com
  version: 0.22.0

generators:
- configmap-generator.yaml

File configmap-generator.yaml:

apiVersion: builtin
kind: ConfigMapGenerator
behavior: replace
metadata:
  name: vault-config
  namespace: vault
literals:
  - thing=stuff
options:
  disableNameSuffixHash: true

Of course, this manifest exists in Helm Chart:

$ helm template vault hashicorp/vault -n test --version=0.22.0 | grep "vault-config" -m1 -B3
apiVersion: v1
kind: ConfigMap
metadata:
  name: vault-config

Expected output

It should generate manifests

Actual output

Error: merging from generator &{0xc000297520 <nil>}: id resid.ResId{Gvk:resid.Gvk{Group:"", Version:"v1", Kind:"ConfigMap", isClusterScoped:false}, Name:"vault-config", Namespace:"vault"} does not exist; cannot merge or replace

Kustomize version

v5.5.0

Operating system

MacOS

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.