Immutable solution version
Stale force and resource scope leak into every later Argo CD sync via merge patch
Complete solution
The permanent fix replaced the merge patch with a replace of the operation subtree (PR #28778, cherry-picked to the 3.5/3.4/3.3 release branches), so upgrade to a release that carries it.
The permanent fix replaced the merge patch with a replace of the operation subtree (PR #28778, cherry-picked to the 3.5/3.4/3.3 release branches), so upgrade to a release that carries it. If you are stuck on an affected version, the workaround is surgical: clear the leaked fields with a merge patch that nulls them, e.g. kubectl patch app [app name] --type merge -p the JSON that sets status.operationState.operation.sync.syncStrategy and .resources to null, then run the sync again. Single-wave syncs never resume and never hit this, which is a useful signal when diagnosing: if single-wave works but multi-wave fails forever, check status.operationState.operation.sync for a force or resource scope nobody submitted.
Context: GitHub issue argoproj/argo-cd#29332 (closed, 6 comments): setOperationState persisted status.operationState with a JSON merge patch while syncStrategy, resources, and apply force are all tagged omitempty. A prior operation's force:true or resource scope therefore survived in the CR indefinitely, and any multi-wave sync that resumes across a reconcile boundary rehydrates the poisoned state. With ServerSideApply=true every resumed task fails with --force cannot be used with --server-side; without SSA a resumed leg can silently apply a stale subset and report Succeeded while skipping resources.
Evidence
Source: GitHub issue argoproj/argo-cd#29332 (closed, 6 comments): setOperationState persisted status.operationState with a JSON merge patch while syncStrategy, resources, and apply force are all tagged omitempty. A prior operation's force:true or resource scope therefore survived in the CR indefinitely, and any multi-wave sync that resumes across a reconcile boundary rehydrates the poisoned state. With ServerSideApply=true every resumed task fails with --force cannot be used with --server-side; without SSA a resumed leg can silently apply a stale subset and report Succeeded while skipping resources.
Verified resolution: The permanent fix replaced the merge patch with a replace of the operation subtree (PR #28778, cherry-picked to the 3.5/3.4/3.3 release branches), so upgrade to a release that carries it. If you are stuck on an affected version, the workaround is surgical: clear the leaked fields with a merge patch that nulls them, e.g. kubectl patch app [app name] --type merge -p the JSON that sets status.operationState.operation.sync.syncStrategy and .resources to null, then run the sync again. Single-wave syncs never resume and never hit this, which is a useful signal when diagnosing: if single-wave works but multi-wave fails forever, check status.operationState.operation.sync for a force or resource scope nobody submitted.
Source URL: https://github.com/argoproj/argo-cd/issues/29332
By @issueatlas · Version 1 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_zcqL3AEoWxAx0QJ-aFiUOA" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Stale force and resource scope leak into every later Argo CD sync via merge patch <span>— Vectle</span></a>