Component replacements x parent resource name alteration inconsistent

[nicolas-boussuge-fintech]

What happened?

Using replacements on the final kustomization.yaml will correctly replace given occurrences.
Using replacements on the component that expects a resource without having it will only replace specific occurrences.

What did you expect to happen?

I would expect replacements to work even when used from the "abstract" components.

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

#base/httproute.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route
spec:
  rules:
    - backendRefs:
        - name: to-be-kustomized
      matches:
        - path:
            type: PathPrefix
            value: /

#base/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress
spec:
  rules:
    - http:
        paths:
          - backend:
              service:
                name: to-be-kustomized
            pathType: Prefix
            path: /

#base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component

resources:
  - httproute.yaml
  - ingress.yaml

#test/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: service

#test/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: prefix-
resources:
  - service.yaml
components:
  - ../base

Adding this code in each kustomization.yaml will produce different results

replacements:
  - source:
      kind: Service
      fieldPath: metadata.name
    targets:
      - select:
          kind: Ingress
        fieldPaths:
          - spec.rules.0.http.paths.0.backend.service.name
      - select:
          kind: Ingress
        fieldPaths:
          - spec.rules.0.http.paths.0.pathType
      - select:
          kind: HTTPRoute
        fieldPaths:
          - spec.rules.0.backendRefs.0.name
      - select:
          kind: HTTPRoute
        fieldPaths:
          - spec.rules.0.matches.0.path.type

Expected output

apiVersion: v1
kind: Service
metadata:
  name: prefix-service
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: prefix-route
spec:
  rules:
  - backendRefs:
    - name: prefix-service
    matches:
    - path:
        type: prefix-service
        value: /
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prefix-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: prefix-service
        path: /
        pathType: prefix-service

All 4 occurrences of the service are correctly prefixed.

Actual output

apiVersion: v1
kind: Service
metadata:
  name: prefix-service
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: prefix-route
spec:
  rules:
  - backendRefs:
    - name: service
    matches:
    - path:
        type: service
        value: /
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: prefix-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: prefix-service
        path: /
        pathType: service

When the replacements section is placed inside the component file, only 1 occurence of the service is correctly prefixed.

Kustomize version

5.8.1

Operating system

Linux

[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.

Details

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.

[nicolas-boussuge-fintech]

Note: I can workaround this by using the name reference transformer instead of the replacements block code

[nicolas-boussuge-fintech]

With a bit more understanding on how this might work, I now think the replacements placed on the Component never actually worked, it just injected service on each field, and then the renaming happened, and following the default nameReferences, it only managed to rename the Ingress backend reference properly.
If this is the case, I guess this issue can be closed.