Key-Protection Backend Activation In Progress

URI: https://docs.ankatech.co/errors/backend-activation-in-progress
HTTP Status: 409 Conflict

When you see this

A deployment key-protection backend activation is in flight, and the request would change what that activation is about to record. An activation contacts the backend and creates the bootstrap tenants' key-encryption keys before it records the declaration, and it holds no database lock across those remote calls. So while it runs, the platform keeps an activation window open on the deployment, and refuses the writes that could replace what it records:

Nothing was changed, and nothing was contacted for the refused request. This is transient: retry once the activation in flight has finished.

How the window behaves.

• It opens as the activation's first act — before the activation reads the backend descriptor or the declaration — so everything the bind depends on is read inside it.
• It is renewed at every phase boundary of the activation: after the self-test, and before each bootstrap tenant's key-encryption key is created.
• It closes on every exit of that activation — success or refusal.
• It goes stale once it has made no progress for 15 minutes. A stale window refuses nothing, and the next activation reclaims it; the reclaim is audited on the platform plane as setup.backend.activation-window.reclaimed. The 15 minutes govern only how soon an abandoned window is freed — they are chosen far above every bounded phase and above the environment host's 300 s client ceiling. A backend that stops answering without failing — a Cloud KMS endpoint or an HSM — can hold an activation until its window goes stale: restore the backend's reachability, then re-run the activation.
• Safety does not depend on the bound. Every write of the bind is a compare-and-set under the deployment_info lock: a tenant's key record is written only while the activation still holds its window with the configuration, credential and declaration it read unchanged, together with the declaration naming the backend, and the key's label is published only after that record commits. The lock is held only for those row writes and their commit, never across a call to the backend. An activation that loses its window therefore writes nothing more, and its refusal removes nothing.
• An activation run after the previous one has finished behaves exactly as before: a re-run adopts the keys already present and completes. What changed is only the concurrent case — a second activation while the first is still running is refused rather than run alongside it.

An activation whose own window was reclaimed while it hung stops at its next phase boundary, key record or commit instead of recording anything; that answer is Key-Protection Backend Activation Window Lost.

The platform settings are not refused by the window. The token selection a running activation reads is already protected: see Token Serial Not Reported By The Declared Backend.

Common Causes

• The activation was started from the Admin Console and, before it finished, again from the console, the API or the CLI — or from the environment host with init-hsm.sh <env> --activate.
• An administrator declared, withdrew or reconfigured the backend, or replaced its credential, while an activation was running.
• An earlier activation's process was interrupted, and fewer than 15 minutes have passed since it last recorded progress.

Response Example

{
  "type": "https://docs.ankatech.co/errors/backend-activation-in-progress",
  "title": "Key-Protection Backend Activation In Progress",
  "status": 409,
  "detail": "A key-protection backend activation is in progress; it last recorded progress at 2026-09-24T14:05:31Z. This change is refused until it ends: the activation window closes when that activation finishes, or is treated as abandoned once it has made no progress for 15 minutes. Retry then. Nothing was changed.",
  "instance": "/api/v3/admin/platform/setup/backend/declare",
  "timestamp": 1787494020,
  "extensions": {
    "requestId": "e4c17a93-0b5d-4f28-8a6e-91d3c2b7f045"
  }
}

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

The detail names when the activation in flight last recorded progress and the bound after which it is treated as abandoned. It names no backend, no coordinate and no caller. The instance is the refused operation's path.

On the environment host

When the host activation (init-hsm.sh <env> --activate) receives this refusal, it prints the platform's detail, states that the host wrote no .env bind and that the platform contacted nothing for this run, and exits 8 — "another activation is in progress". Re-run --activate once that activation has finished. One case is the host's own: if an earlier --activate from this host gave up at its 300 s client limit and admin-api was then restarted (envctl.sh <env> up) while that activation was still running, its window is released only after 15 minutes without progress — re-run once they have passed. Exit 8 is not a failure of the environment, and it must not be answered with any recovery that recreates or re-declares anything.

How to Resolve

1. Wait for the activation in flight to finish — the setup status (GET /api/v3/admin/platform/setup/status) and the console's HSM / Cloud KMS screen show its outcome.
2. Retry the refused request.
3. If no activation is running and the refusal persists, an earlier one was interrupted: it is honoured until it has made no progress for 15 minutes (the detail names when it last did). After that it no longer refuses anything, and the next activation reclaims it.

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