A request that would stand behind the vault

How the object API refuses a request that would queue behind a Skarbiec read, with the line of the wait it would have stood behind. The wait lines themselves are described on What a machine-interface command is waiting on.

Refused with the line it would wait on

The object API compares every bearer against Skarbiec: a namespace bearer's version on each object request, the bearer itself when the version moved, the release publisher's, the host-health role's and the service and machine clients' on each request of theirs. Each of those reads is a wait the server writes as the wait page describes, under a key (the namespace, release:<item>, host-health, service:<item>, machine:<item>). A request is never queued behind another's read:

• A namespace bearer read holds its namespace while it runs. A request that finds its key held is answered 503 at once, with the body {"error":"object authorization unavailable","cause":"czekam: …"} — the czekam line of the read it would have stood behind, so the caller reads what the server waits on, where and since when.
• Once a read under a key failed, every later request under it is answered 503 with that failure's blad czekania line as cause (the vault's own answer in przyczyna, for example HTTP 403 or HTTP 503 with gpg's waiting for lock (held by <pid>)), except the first, which reads again while holding the key; its success clears the failure.
• A request gated on a closed authorization boundary answers the same body with the boundary's label, its verifier's last sentence and when that verdict was reached as cause. The error word names the boundary (object, release, service, registry, host-health); the machine routes carry the same cause in their AUTH_UNAVAILABLE message.

The same state in state.json

GET /api/state.json carries the same state under vault: consultations.<key>.open is the czekam line of the read holding the key and consultations.<key>.failed the blad czekania line of its last failed read, each null when there is none; keyring_lock_repair is the declared skarbiec crypto repair the vault host's own object API last ran because a vault answer named the process holding the keyring's lock — its holder, started and outcome (null while it runs) — or null (Declared repair). stado doctor's gateway-auth row names the same holder and the repair when the vault answers its verifiers that way. Nothing here times a wait out: the server's own read still runs to the vault's answer, and only the requests that would have queued behind it are refused.