Skip to content

Custody Write Conflict

URI: https://docs.ankatech.co/errors/custody-write-conflict
HTTP Status: 409 Conflict

When you see this

A re-wrap step found that one of the tenant's keys changed while the step ran — for example a stateful signature advanced the key's state between the read and the write. Every re-wrap write is a compare-and-set on the key's version, so the step wrote nothing rather than overwrite the newer key.

This problem is answered by the key service to the platform's own administration service while it drives a key custody move, one bounded re-wrap step per call. It is never answered to a browser, an SDK or an API client, so its instance names an internal call and is not reproduced here. An operator sees its effect on the move instead: the move's state on the tenant's key custody read, and the audit trail of the move.

Response Example

{
  "type": "https://docs.ankatech.co/errors/custody-write-conflict",
  "title": "Custody Write Conflict",
  "status": 409,
  "detail": "A key changed while the step ran; nothing was written. Retry the step.",
  "correlationId": "6a0c2f9e-3d71-4b58-8e24-c1f5a7d9b036",
  "timestamp": 1793696400
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. The detail is fixed: it names no tenant, key, key-encryption key or count.

How to Resolve

  1. Nothing. The engine asks for the same step again at its next wake-up; the conflict is transient by construction.
  2. If a move stays on the same state for a long time, look at the tenant's signing traffic: a key signing continuously makes its re-wrap retry until a write lands between two signatures.

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