Errors
409 - optimistic-concurrency conflict
What happened
A conditional write used an old row version. Optimistic concurrency control means the write is accepted only if the row still has the version supplied in If-Match.
- Read the latest recordFetch its current fields and version.
- Reconcile the editDecide which changes still apply.
- Use the new versionSend a conditional write with the current version.
- Check the outcomeVerify success or handle another conflict within a bounded retry policy.
Request that triggers it
A conditional PUT where the If-Match version no longer matches.
curl -X PUT "https://$OC_HOST/v1/tenants/$OC_TENANT/rows/shop.customers/c_42" \
-H "Authorization: Bearer $OC_TOKEN" \
-H "If-Match: 17" \
-H "Content-Type: application/json" \
-d '{"id": "c_42", "email": "alice@example.com", "tier": "platinum"}'Read the response
{
"error": "write_conflict",
"message": "row 'c_42' is at version 18, expected 17",
"retry": true,
"current_version": 18
}Fix the request
- Read the latest row and version.
- Reapply and validate the intended change against that row.
- Submit the new value with the new If-Match version.
- Stop or retry within a bounded application policy if it conflicts again.
Keep in mind: Version checks are opt-in; ordinary writes are last-writer-wins. Repeating the unchanged request with the old version will fail again.
Common causes
- Two workers picking up the same job from a queue and racing on the same row.
- Background reconciler and user-facing edit landing in the same millisecond.
- Re-using a stale version number from an in-memory cache.
- Mobile client with an offline edit syncing after the server already advanced.
- Wrong row's version copied into
If-Matchfrom another response.
Continue
See error handling and retries, or return to error examples.