Skip to content

Impersonation Session Already Live

URI: https://docs.ankatech.co/errors/impersonation-session-already-live
HTTP Status: 409 Conflict

When you see this

A support operator tried to open a second impersonation session under the same tenant consent grant while one is still live. A grant admits at most one live session per operator, so the tenant's view of who is acting as them stays unambiguous.

Two services emit this type. ankasecure-admin-api raises it on the internal session-admission hop; ankasecure-auth-api re-mints it on the token-exchange grant when that hop answers 409, so the operator is told the real cause instead of an upstream-unavailable 502. Auth-api's body carries its own wording, its own instance and no correlation member — the relay contract propagates a status, never an upstream identity.

Common Causes

  • The operator already holds a live session under this grant and has not ended it.
  • Two concurrent exchanges raced; the loser receives this refusal and no access token at all.

Response Example

From ankasecure-auth-api, on the token-exchange grant:

{
  "type": "https://docs.ankatech.co/errors/impersonation-session-already-live",
  "title": "Impersonation Session Already Live",
  "status": 409,
  "detail": "A live impersonation session already exists for this operator under this authorisation. End the existing session before opening another.",
  "instance": "/api/v3/auth/token",
  "timestamp": 1730000000
}

From ankasecure-admin-api, on the internal admission hop:

{
  "type": "https://docs.ankatech.co/errors/impersonation-session-already-live",
  "title": "Impersonation Session Already Live",
  "status": 409,
  "detail": "A live impersonation session already exists for this operator under this authorisation. End the existing session before opening another — a grant admits at most one live session per operator, so that the tenant's view of who is acting as them is unambiguous.",
  "instance": "/api/v3/internal/impersonation/tenants/7c9e6679-7425-40de-944b-e07fc1f90ae7/sessions",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

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

Neither body names a session, a token identifier, a window or an operator. This is a refusal, not an outage, and it is not retryable: the slot is held until the existing session ends or lapses at its own expiry. An expired-but-unclosed session is never the cause — the admission path closes such a row first and only refuses when the existing session is genuinely live.

How to Resolve

  1. End the operator's existing impersonation session, then re-run the exchange.
  2. If no session is expected to be open, wait for the existing one to lapse at its own expiry — no retry can clear it sooner.
  3. If two exchanges were issued concurrently, keep the one that succeeded; the loser was granted nothing.

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