Skip to content

Serialised Operation Timed Out

URI: https://docs.ankatech.co/errors/serialised-operation-timeout
HTTP Status: 503 Service Unavailable

When you see this

Another request was completing an operation that must be applied one at a time, and the wait for it exceeded the configured bound. Nothing was changed.

503 and not 500: nothing is wrong with the request and nothing is defective — the same body a moment later succeeds. A 500 would send an operator looking for a defect that does not exist. Nor 409: the conflict this lock serialises was never evaluated, so claiming one would assert something this deployment does not know.

Common Causes

  • Two writes to the same serialised resource arriving close together, where the first held the lock past the wait bound.
  • A burst of concurrent declarations or bindings from an automation loop.
  • An unusually slow write holding the lock — for example one contending on a busy database.
  • A compliance remediation execution waiting on its action's follow-up row (Admin API). Confirming a step (POST …/compliance-remediation/{packId}/actions/{actionKey}/executions) locks the action's row to reserve its run and waits at most 5 seconds; the holder is another confirmation of the same action. Nothing was reserved or executed; Retry-After: 5.
  • A change to a person's identity waiting on the identity's row lock (Admin API). An assisted recovery, a forced password reset, an authenticator removal, the completion of an activation or enrolment, and the cancellation of a pending activation each wait at most 5 seconds for the identity's row; the holder is another of these operations on the same person. Nothing was changed; Retry-After: 5.
  • A sign-in policy write waiting on the platform or tenant lock (Admin API). The tenant authentication posture, a member's authentication path, the deployment authentication allowance, the platform authentication posture and the withdrawal of a provider's platform approval are decided one after the other, so none passes its check against a state another is changing. Each waits at most 5 seconds; the holder is another of these writes. Nothing was stored; Retry-After: 5.
  • An identity provider change waiting on the provider's row lock (Admin API). The edit, enable, disable and delete of a provider, the removal of its trust anchors, its approval for platform sign-in, and the two short steps of its self-test each wait at most 5 seconds for the provider's row; the holder is another of these operations on the same provider. The self-test holds the row only to read the provider before its connection test and to record the result after it, never during the test. Nothing was changed; Retry-After: 5.
  • A key lifecycle change waiting on the key's row lock (Admin API). Every key-level writer — metadata patch, revoke, suspend, reactivate, archive, mark-for-destruction, cancel-destruction and the final delete — and every per-version writer of a key's material — revoke, mark-for-destruction, cancel-destruction and destroy — waits at most 5 seconds for the key's rows. The holder is another lifecycle change of the same key, or Core API committing a stateful signature's one-time-index reservation on an XMSS, XMSS^MT or LMS/HSS key.

Response Example

{
  "type": "https://docs.ankatech.co/errors/serialised-operation-timeout",
  "title": "Serialised Operation Timed Out",
  "status": 503,
  "detail": "Another request is currently completing an operation that must be applied one at a time, and the wait for it exceeded the configured bound. Nothing was changed. Retry the request.",
  "instance": "/api/v3/admin/tenants/3f9a1b62-5d47-4c8e-b0a2-91d7e4f60cc5/workload-identity/issuers",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

The body names no lock key, no issuer URL and no tenant. The wait tells the caller nothing about who was holding the lock, which is also what stops it becoming an existence oracle for a concurrent declaration.

How to Resolve

  1. Retry the request. Nothing was written, so the retry is safe and is the intended response.
  2. If an automation issues these writes, serialise them client-side or add a short backoff rather than firing them concurrently.
  3. If it persists, investigate what is holding the operation open for longer than the wait bound — persistent occurrences point at a slow write, not at contention.

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