Use this playbook to separate true write conflicts from stale precondition failures, then apply safe re-fetch, optimistic-lock, and retry choices.
Last reviewed: February 23, 2026|Editorial standard: source-backed operational guidance
Treat stale client state as validator mismatch where client ETag-version no longer matches server state, usually surfacing as 412. Treat true conflict as domain transition collision that remains invalid even after refresh, usually surfacing as 409.
Retries keep failing when requests reuse stale validators and unchanged condition expressions. The server reevaluates the same predicates and returns the same conflict outcome. Successful retries require fresh state, updated validators, or changed mutation intent.
Re-fetch and auto-retry only idempotent flows where fresh validators can resolve stale state. Surface conflict when the business decision changed, such as competing edits or invalid state transition requiring user intent.
Idempotency keys should map to one caller intent scoped by principal, operation, and target resource. AWS and Azure APIs support idempotency patterns on create and mutation paths, so repeated submissions with the same key can return the original result instead of creating duplicates. Idempotency keys prevent duplicate-create 409 outcomes that come from retrying the same intent. Real state-transition or version conflicts still require conflict handling and can still surface as 409 or 412.