manifest-generate-paths does not reliably detect diffs during normal refresh

[caiomartin]

• I've searched in the docs and FAQ for my answer
• I've included steps to reproduce the bug
• I've pasted the output of "argocd version"

Describe the bug

Applications using:

argocd.argoproj.io/manifest-generate-paths

do not reliably detect diffs during normal refresh operations in monorepo environments.

Argo CD correctly updates the application revision/hash after commits, but the application still remains in "Synced" state.

The correct diff is only detected after performing a Hard Refresh.

This issue is happening in large monorepo environments using Helm + AVP CMP plugin.

The affected applications have Auto-Sync disabled.

The annotation improves performance significantly by reducing unnecessary manifest generation and reconciliation load, but appears to introduce cache/diff consistency issues.

Official docs:

• https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/#manifest-paths-annotation
• https://argo-cd.readthedocs.io/en/stable/user-guide/annotations-and-labels/

To Reproduce

1. Configure an Application using:

argocd.argoproj.io/manifest-generate-paths

2. Use a Git monorepo

3. Commit changes inside the monitored path

4. Wait for normal refresh/reconciliation

5. Observe that:

   • revision/hash changes
   • app remains "Synced"

6. Execute Hard Refresh

7. Observe the application finally becoming "OutOfSync"

Expected behavior

After changes inside the configured "manifest-generate-paths":

• Normal refresh should detect the new diff
• The application should become "OutOfSync"

Screenshots

Can provide if needed.

Version

argocd: v3.2.1

Environment

• Git monorepo
• Helm
• AVP CMP Plugin
• Multiple repo-server replicas
• Multiple application-controller replicas

Environment scale:

• ~2k applications
• ~200 clusters

Additional context

We also evaluated:

• "argocd.argoproj.io/refresh: hard"
• "argocd.argoproj.io/compare-options"
• "argocd.argoproj.io/sync-options"

"refresh: hard" works only as an operational workaround because it invalidates repo-server caches and increases load significantly at scale.

The issue appears related to:

• manifest cache invalidation
• repo-server cache behavior
• diff generation during normal refresh
• interaction between CMP plugins and "manifest-generate-paths"

[dhruvac29]

@caiomartin i would love to contribute if it is available ?

Thanks for the detailed report. Based on the described behavior, this looks like the normal-refresh optimization path for manifest-generate-paths may be incorrectly reusing/promoting cached manifests.

The relevant flow appears to be:

• controller/state.go calls UpdateRevisionForPaths when argocd.argoproj.io/manifest-generate-paths is set.
• reposerver/repository/repository.go checks changed files between the synced and resolved revisions.
• If it decides none of the configured paths changed, it calls SetNewRevisionManifests(...) to move/reuse the old manifest cache under the new revision and returns Changes: false.

The symptom here:

• revision/hash advances
• app remains Synced
• hard refresh later detects the real diff

suggests that UpdateRevisionForPaths is sometimes returning Changes: false even though generated manifests would change, causing stale cached manifests to be reused for the new revision.

Proposed fix direction:

1. Add a regression test for a CMP-backed app with manifest-generate-paths, where a commit changes a file under the configured path. Normal refresh should return Changes: true, regenerate manifests, and mark the app OutOfSync.

2. In UpdateRevisionForPaths, avoid calling SetNewRevisionManifests unless the repo-server has definitively proven that no relevant files changed. For CMP/plugin sources, this may need to be more conservative because generated output can depend
   on plugin env, Helm values, AVP inputs, and files outside the obvious app path.

3. Add debug logging around:

   • refreshPaths
   • resolved vs synced revision
   • changed files count/sample
   • AppFilesHaveChanged(...) result
   • whether SetNewRevisionManifests was called

This would make it much easier to confirm whether the wrong Changes: false path is being taken in large monorepo/CMP setups.

Operational workaround remains hard refresh, but the safer code-level behavior would be: when manifest-generate-paths + CMP dependency detection is uncertain, prefer Changes: true and regenerate manifests instead of promoting an old manifest
cache entry to the new revision.