Skip to content

Concurrent Modification

URI: https://docs.ankatech.co/errors/concurrent-modification
HTTP Status: 409 Conflict

When you see this

The resource you tried to update was changed by another request between the time you read it and the time you wrote it. Your write was rejected to prevent silently overwriting the newer state.

Common Causes

  • A concurrent write to a key's alias during a rotation. The alias — the pointer naming the key's current primary material version — moved between the rotation's read and its commit, and the rotation's own write to it was rejected at commit. A write that changed the primary material itself answers the generic conflict instead, and so does a material version number that already exists. Neither type identifies the writer: the two differ in which record the server observed moving — the key's material or its alias — not in who moved it, nor in what you should do about either. Another rotation of the same key reaches neither: rotations of one key are applied one at a time, and the second is refused material-version-moved.
  • A rotation waited too long for its key. Another rotation, revocation or destruction of the same key held it, and the rotation's wait for the key is bounded. Nothing was written. Retry the rotation: a resend under the same Idempotency-Key returns the applied rotation if the writer it waited on was that same rotation.
  • A stale version of the resource being submitted after another change landed.
  • Retrying a write without first re-reading the current resource state.

Response Example

{
  "type": "https://docs.ankatech.co/errors/concurrent-modification",
  "title": "Concurrent Modification Conflict",
  "status": 409,
  "detail": "The resource was modified concurrently. Please retry the operation.",
  "instance": "/api/v3/admin/tenants/2f1c9d84-6b2e-4d3a-9f57-0a1b2c3d4e5f/keys/my-mlkem-key/rotations",
  "timestamp": 1751500800,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. The example above is an Admin API body, where the correlation identity is extensions.requestId; the Core API and the PQC Handshake API instead emit a top-level correlationId. Read the member your service emits — see Error Index & Overview.

How to Resolve

  1. Re-fetch the resource to obtain its current state.
  2. Re-apply your change on top of the latest version.
  3. Re-submit the request. If conflicts persist, serialize concurrent writers or add a short backoff between attempts.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.