The short version
- 01Read the response detail to identify the conflicting resource or operation.
- 02Preserve local edits before loading the latest saved version.
- 03Compare and reconcile changes when the server reports a version conflict.
- 04Check the existing job when the service reports an operation already running.
- 05Use delayed retries only for conflict types the provider documents as retryable.
- 06Verify the final saved state after resolving the conflict.
Raw message
409 Conflict
Likely causes
- A saved version conflicts with a newer version on the server.
- A service rejects overlapping operations on the same resource.
- A required parent resource is absent in a provider's workflow.
- An application-specific concurrency rule prevents the requested change.
A conflict describes state that needs attention
409 reports a conflict with the target resource's current state. It may be recoverable after the conflict is resolved. Read the response body: the number alone cannot distinguish a stale edit from an operation already in progress.
MDN gives examples involving version conflicts and overlapping jobs. These examples do not create a universal rule for every API. A service can also use a different status for a failed conditional update, so follow its documented response contract.
If saving or syncing produces a conflict
Our recommendation is to preserve your unsaved text or file first. Open the latest saved version separately if the application permits it, compare the differences and use its merge or conflict-resolution workflow. Refreshing away your only local copy removes evidence needed to reconcile the changes.
If the message names an existing operation, inspect that operation's status before starting another. If the service gives no explanation, report the affected item and action. Avoid selecting an overwrite option merely to dismiss the error; first establish which changes the final version should contain.
If an API returns 409
Branch on the documented error code and resource state, not solely on 409. Microsoft Graph, for example, lists an absent parent folder as one possible conflict and gives delayed-retry guidance specifically for Directory_ConcurrencyViolation. The latter is not permission to retry every conflict indefinitely.
For a documented transient conflict, apply the provider's delay policy and honor Retry-After when supplied. For a stale version or missing prerequisite, reconcile the data or resource first. Microsoft Graph's error model is an implementation example, not a shared schema across APIs.
Our verification sequence is to reproduce with one writer, then with the competing operation present, and check that the client preserves edits and explains the resolution. After a successful response, read back the resource to confirm the intended final state.
Sources and review notes
Checked on . Based on HTTP semantics, MDN and Microsoft Graph documentation. Edit-preservation and verification steps are editorial guidance; conflict types and retry policies are service-specific.