ArgoCD appears to be removing field from gateway.networking.k8s.io Gateway resource

[thandleman-r7]

Checklist:

• I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• I've included steps to reproduce the bug.
• I've pasted the output of argocd version.

ArgoCD seems to be removing spec.infrastructure.parametersRef.group from the resource below. This causes the following error:

Gateway.gateway.networking.k8s.io "egress-istio-waypoint" is invalid: [spec.infrastructure.parametersRef.group: Required value, <nil>: Invalid value: "null": some validation rules were not checked because the object was invalid; correct the existing errors to complete validation]

Gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: egress-istio-waypoint
  namespace: istio-egress
  annotations:
    argocd.argoproj.io/sync-options: Validate=false
spec:
  gatewayClassName: istio-waypoint
  infrastructure:
    parametersRef:
      group: ""
      kind: ConfigMap
      name:  egress-istio-waypoint-config
  listeners:
    - name: mesh
      protocol: HBONE
      port:  15008

ConfigMap:

apiVersion: v1
data:
  deployment: |
    spec:
      replicas: 3
      template:
        spec:
          containers:
            - name: istio-proxy
              resources: 
                limits:
                  memory: 256Mi
                requests:
                  cpu: 50m
                  memory: 128Mi
  horizontalPodAutoscaler: |
    spec:
      minReplicas: 2
      maxReplicas: 9
      scaleTargetRef:
        kind: Deployment
        name: egress
      metrics:
        - type: Resource
          resource:
            name: cpu
            target:
              type: Utilization
              averageUtilization: 80
  podDisruptionBudget: |
    spec:
      minAvailable: 1
      matchLabels:
        gateway.networking.k8s.io/gateway-name: egress
kind: ConfigMap
metadata:
  name: egress-istio-waypoint-config
  namespace: istio-egress

This issue does not occur when trying to apply this resource via kubectl apply, so it appears to be something specific within ArgoCD. Additionally, the issue is not that it is treating an empty string as invalid. Any value placed in Group results in the same error.

Server-Side for Client-Side apply does not seem to be a factor here, as both result in the same error.

Here are some Istio docs showing support for this field: https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment

Here are the Gateway API docs that mention this field:

• https://gateway-api.sigs.k8s.io/reference/1.4/spec/#localparametersreference
• https://gateway-api.sigs.k8s.io/reference/1.4/spec/#group

ArgoCD Version: v3.1.8+becb020
ArgoCD Cluster Version: v1.33.5-eks-3cfe0ce
Destination Cluster Version: v1.33.5-eks-3cfe0ce

To Reproduce

1. Install the Gateway API CRDs to target cluster: kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.1/standard-install.yaml
2. Install Istio in Ambient mode to target cluster: istioctl install --set profile=ambient --skip-confirmation
3. Create a simple Application that generates the above Gateway and ConfigMap.

Expected behavior

ArgoCD should create the gateway as specified.

Screenshots

Diff shown in ArgoCD UI:

Error:

Version

argocd: v3.1.8+becb020
  BuildDate: 2025-09-30T15:33:46Z
  GitCommit: becb020064fe9be5381bf6e5818ff8587ca8f377
  GitTreeState: clean
  GoVersion: go1.24.6
  Compiler: gc
  Platform: linux/amd64

Logs

Couldn't find anything besides the error see in the UI.

[thandleman-r7]

I also just tried updating to the latest Argo v3.2.1+8c4ab63 and the issue persisted.

[thandleman-r7]

Okay there actually seems to have been a bit of user error here, I was able to get it to apply fine today. But I think it may highlight another issue (?)

he chart we are using to generate this waypoint is very new, and I have been manually force pushing to our helm repo to test it with the version unchanged. Initially, I forgot to put group under parametersReference, so I fixed that and pushed it up to the Helm repo.

The changes were reflected in the diff view as can be seen in the screenshot after a hard refresh, but I have a feeling somewhere in the backend the old chart was being used as pointed to by the error. I have done similar things in the past without issue as long as I used a hard refresh.

If the guidance here is "dont be lazy and just push a new version" I am totally fine with that :)