Argo CD Self-Heal Reconciliation Boundary with Server-Side Apply Idempotency

Argo CD's automated sync policy with selfHeal enabled triggers periodic reconciliation by comparing the cached desired manifest against the live Kubernetes state. When a sync retry occurs without changes to the application source, the server-side apply leverages Kubernetes API idempotency to avoid duplicate writes. However, the precise condition under which a retry transitions from an idempotent no-op to a full reconciliation remains ambiguous when external modifications alter resources between retry cycles. This boundary involves Argo CD's operationState tracking, the sync algorithm's state-detection logic, and how Kubernetes strategic merge patches are evaluated during reconciliation.

• How does Argo CD distinguish between a transient retry and a legitimate state change when using server-side apply with strategic merge patches?
• What adjustments to operationState tracking affect whether a retry triggers a full reconcile or remains inert?
• Under what conditions does selfHeal initiate a full reconciliation versus a no-op retry when the live Kubernetes state has been partially modified outside Argo CD?