ArgoCD does not detect key removal or container reduction in ConfigMap / Secret / Deployment

[yilas]

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.

Describe the bug

When reducing a manifest (e.g., removing a key in a ConfigMap or Secret, or removing a container from a Deployment), ArgoCD does not detect any difference between Git and the cluster.
The application stays Synced, no diff is shown, and no update is applied to Kubernetes.
Even worse, the removed part remains in the live object.

To Reproduce

1. Create a ConfigMap and sync it with ArgoCD:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: test-configmap-001
   data:
     test-1.json: |-
       { "description": "Test ConfigMap to diagnose Argo sync issues" }
     test-2.json: |-
       { "description": "Test ConfigMap to diagnose Argo sync issues" }

2. Commit and push → ArgoCD creates the ConfigMap correctly

3. Modify the manifest by removing one key

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: test-configmap-001
   data:
     test-1.json: |-
       { "description": "Test ConfigMap to diagnose Argo sync issues" }

4. Commit and push again

5. Observe in ArgoCD

   1. The application remains Synced
   2. No diff is shown in the UI
   3. The cluster-side ConfigMap still contains the deleted key (test-2.json)

6. Similar behavior occurs with:

   1. Secrets (removing data keys)
   2. Deployments (removing containers from spec.template.spec.containers)

Expected behavior

• ArgoCD should detect that the manifest in Git is smaller (a key or container was removed) or is changed.
• The application should become OutOfSync.
• A sync or auto-prune should delete the missing fields or containers in the live object.

Screenshots

• LIVE MANIFEST

• DIFF

• DESIRED

Version

❯ argocd version
argocd: v3.1.8+becb020
  BuildDate: 2025-09-30T16:04:21Z
  GitCommit: becb020064fe9be5381bf6e5818ff8587ca8f377
  GitTreeState: clean
  GoVersion: go1.24.6
  Compiler: gc
  Platform: linux/amd64
argocd-server: v3.1.8+becb020
  BuildDate: 2025-09-30T16:04:21Z
  GitCommit: becb020064fe9be5381bf6e5818ff8587ca8f377
  GitTreeState: clean
  GoVersion: go1.24.6
  Compiler: gc
  Platform: linux/amd64
  Kustomize Version: could not get kustomize version: exec: "kustomize": executable file not found in $PATH
  Helm Version: v3.17.3+ge4da497
  Kubectl Version: v0.33.1
  Jsonnet Version: v0.21.0

Version of ArgoCD server : v3.1.0 (but we have the same behavior with version 2.14.9)

[choejwoo]

Hello, thank you for creating this issue.
I’ve been testing it in my environment as well, but I have a few questions.

1. In scenario 5, even after performing a Sync, does the ConfigMap data not get pruned?
2. If you are currently using the Legacy Diff(default method), could you try applying the Server-Side Diff as described in the documentation?

Please check when you have a moment. It would be helpful for resolving this issue. Thank you!

[yilas]

Hello, thank you for creating this issue. I’ve been testing it in my environment as well, but I have a few questions.

Hello @choejwoo !
Thank you for your reply.

1. In scenario 5, even after performing a Sync, does the ConfigMap data not get pruned?

No. even after performing a Sync (with different options such as FORCE and SERVER-SIDE APPLY), the data remain present in the live object. No pruning occurs.

2. If you are currently using the Legacy Diff(default method), could you try applying the Server-Side Diff as described in the documentation?

I have just tested with the Server-Side Diff strategy, but unfortunately the behavior is identical : ArgoCD still does not detect or apply the removal.

Please check when you have a moment. It would be helpful for resolving this issue. Thank you!

Sure. I’ll keep monitoring this thread for any additional tests or logs that might help the investigation.
Thanks again for your time and support.

[jespersm]

I've ht this issue also (on 3.1.7):

• An application chart had generated an opaque secret containing some values in it's data dictionary, for use with a pod's envFrom/secretRef-mechanism).
• Then, the source was changed with a few of the values removed, and the application was sync'ed
• Result state is similar to the bug above:
  • green sync status
  • blank diff on the secret
  • visible difference between the desired and live manifest, where the removed keys are still present in the live manifest (and indeed also in the pod, through envFrom)
  • Only a replace can fix the situation
• Issue is the same for legacy and server-side diff'ing

Could this be due to a side-effect of the handling of Kubernetes-API-provided values in a dict (e.g. default values like a Deployment's spec/progressDeadlineSeconds), where the diff logic (correctly) ignores live dictionary values without corresponding desired key?
This ought not apply to "opaque" data such as data on a secret?

[choejwoo]

@yilas
I’m testing various ways to reproduce your issue. It’s kind of strange. I think this issue might only happen in a specific case.

1. Tested locally with plain YAML (ArgoCD v3.1.8)
   I attached a video showing my test. As you can see, even when the app is in sync, after I modify and sync the ConfigMap, the deletion is properly reflected. In this case, I remember your issue was reproducible at first, but after changing some configurations. It started to work like this.

1_delete_in_sync-1-1.mov

2. Tested in my production ArgoCD (v2.7.2)
   I’m using Helm with templates. I updated my values.yaml file, and ArgoCD immediately detected the change (status changed to OutOfSync) even when I deleted just a single key in the ConfigMap. Sync also worked correctly.

2_delete_in_2.7.mov

3. Tested locally with Helm (ArgoCD v3.1.8)
   With case1 and case2 I think using helm templates, ArgoCD easily detects changes in the ConfigMap.
   However, as shown in my video, I was able to reproduce your issue under certain conditions.

3_delete_issue_reprod.mov

I think I need more time to test and identify the exact root cause, or maybe another developer might be able to help pinpoint it. If you want, you can test Plain YAML and Helm with my forked repos.
I’ll also keep testing to see which part is causing the issue. Thanks for the reply!

[mikutas]

I've ht this issue while updating Helm chart 8.6.3 -> 9.0.1 which contains ConfigMap key removals
(EDITED: We have enabled ServerSideApply=true on argo-cd Application)

• fix(argo-cd): Align default values of argocd-cmd-params-cm ConfigMap to upstream argo-helm#3540

manifest diff in CI
19 key removals from ConfigMap

Details

manifest diff in Argo CD
only 4 removals detected, and others not detected

Details

---

remains in the live object after Sync

[yu-croco]

I've ht this issue while updating Helm chart 8.6.3 -> 9.0.1

argoproj/argo-helm#3540

Hi @mikutas , Regarding the behavior of argo-helm v9.0.0, maybe this is because of wrong doc in argo-helm. Please refer argoproj/argo-helm#3546 . 🙏
*We removed from argo-hlem but users can still override them same as older versions but changelog was wrong. We are sorry for the inconvenience.

[gnunn1]

I've been testing the various Argo CD Diff schemes over the last few weeks for a talk on ArgoCon. With Argo 3.1 I'm finding that the Server-Side diff doesn't pick up field/key deletions in a git manifest whereas the Legacy diff (via last-applied-annotation) and Structured-Merge-Diff (via field managers) do pick up the deletion correctly.

https://github.com/gitops-examples/what-the-diff/tree/main/git-changes

Interestingly kubectl diff --server-side has the same issue so I feel like this is potentially a bug on the Kubernetes side? I feel like this is a bug because while kubectl/Argo CD Server Side diff doesn't flag the deletion kubectl apply --server-side and Argo CD Sync Apply (both client side and Server-Side-Apply) successfully remove the field as expected. IMHO the client/server side diff needs to align with the client/server side apply for consistency.

[reggie-k]

May be related:
#4537

[bavjackson]

I'm using ArgoCD to deploy Kube-Prometheus-Stack and it looks like it's not picking up that I've removed the extraContainers arg, and still keeping that in the prometheus spec that's deployed.

Given @gnunn1's comment about the new schema not picking up deletions I'm going to try the legacy diff for one run and see if it helps.

[jpatallah]

We are using argocd 3.2.5 and had this issue occur when updating values in a configmap. Autosync was on, and the application health was green. Sync said successful however the configmap wasn't updated. I attempted a hard refresh..didn't help. I had to delete the configmap by hand and resync for it to have the proper falues.