Skip to content

Key-Encryption Key Destruction In Flight

URI: https://docs.ankatech.co/errors/kek-destruction-in-flight
HTTP Status: 409 Conflict

When you see this

A platform administrator asked to cancel the pending destruction of a tenant's key-encryption key while the destruction request may still be waiting for its provider's answer, and the cancel was refused. Nothing was changed.

A tenant key-encryption key is destroyed at its provider or HSM, never only in the platform's records. A destruction request moves a RETIRED key to PENDING_DESTRUCTION, and the key becomes DESTROYED only once a read of the provider confirms it gone. Until then a Cloud KMS destruction can be cancelled, which returns the key to RETIRED. A key object on an HSM is normally destroyed when the request answers, so its cancel is refused with Key-Encryption Key Already Destroyed instead.

Common Causes

  • The destruction request is recorded before its provider is called, with the request instant as a provisional destructionDueAt. While destructionDueAt still equals destructionRequestedAt and the request is less than 170 seconds old, the provider call may still be running, and a schedule it writes could land after the cancel.
  • The 170 seconds are the limits the platform enforces on one destruction: one call deadline to build the provider's client (10 seconds), the destruction's total budget (120 seconds), one more call deadline for the call in flight when that budget is spent (10 seconds), and a 30-second allowance for the clocks of two replicas.
  • On a Cloud KMS key, this is the window before the provider's due date is recorded.
  • On an HSM, destructionDueAt is normally the instant the HSM destroyed the object, and a cancel of that destruction is refused kek-destruction-already-destroyed. A cancel is refused in flight on an HSM only while destructionDueAt stays the request instant: when the HSM already held no object under the key's label at the request, when it gave no answer to the destruction, or when its answer could not be recorded. Past the 170 seconds a cancel reads the token: it succeeds if the object is still there and is refused kek-destruction-already-destroyed if it is gone.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-in-flight",
  "title": "Key-Encryption Key Destruction In Flight",
  "status": 409,
  "detail": "The destruction request of this key-encryption key is still waiting for its provider's answer. Cancel it once its due instant is recorded, or after the request's bound has passed. Nothing was changed.",
  "instance": "/api/v3/admin/platform/tenants/8f14e45f-ceea-467a-9575-0d5b2a1f3c11/key-custody/keks/3c1f7a9e-2b44-4e0d-8f6a-91d2c7b5e0aa/cancel-destruction",
  "timestamp": 1793696400,
  "extensions": {
    "requestId": "9c41e7a2-5b08-4d3f-a6e1-2f7c90b4d815"
  }
}

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

How to Resolve

  1. Read the lineage entry again. Once its destructionDueAt is the provider's due date rather than destructionRequestedAt, ask for the cancel again.
  2. If destructionDueAt still equals destructionRequestedAt, ask again once 170 seconds have passed since destructionRequestedAt.

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