What Happens to an Extendable Nomad Client Token When Its ACL Policy Is Revoked?

Nomad's ACL framework allows client tokens to be marked extendable so their TTL renews automatically when the token is used, supporting long-running allocations without manual rotation. When an operator revokes the underlying ACL policy to enforce least privilege, the documented behavior states that subsequent API calls are rejected; however, the exact interaction between an active auto-extend cycle and revocation remains ambiguous.

Because auto-extend applies only to client tokens and server-side tokens do not receive automatic renewal, the de-synchronization may differ by token type and by Nomad version. It is also unclear whether a token scoped to multiple jobs exhibits the same renewal-then-rejection sequence as a single-job token, or whether the audit log records a revocation detected mid-renewal.

Does an extendable client token continue to auto-extend its TTL after the governing ACL policy is revoked but before the next API call is rejected? How does this behavior change for tokens scoped to multiple jobs, and which Nomad versions should be tested to confirm the current semantics?