## TL;DR

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.

## When to use

You are seeing this: 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. Use this skill when you run into "Stale force and resource scope leak into every later Argo CD sync via merge patch".

## When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

## Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

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.