B · Busy ​

Sent when an acquire request (A) arrived but a key, waiter, pending-request, or memory-admission cap had been reached. The request was not admitted. It definitively did not acquire the lock, and its frame was not invalid.

owner is the value from the request echoed back verbatim as a correlator — it tells you exactly which acquire attempt was rejected (see Reply Matching Rules).

Client Handling ​

Official clients return a correlated B immediately as a Busy/Capacity-class error and do not automatically resend the same logical acquire. A caller that wants to try again sets an overall application deadline and backoff, then explicitly starts a new acquire with a new owner.

An actually observed B proves non-acquisition, so a separate new call is safe. Never infer B from a request whose response was not observed; that result is Indeterminate.

Byte notation: op is an ASCII character, owner is binary (u64, big-endian), and key is UTF-8 text (variable-length, shown as N in the structure). The trailing \n is 0A. The fixed header is a binary value that may contain 0x0A, so it must be consumed by byte count first, before scanning for the newline.

Flow ​

The caps are memory guardrails. They reject new acquire work before the daemon can OOM, while reserving resources for exact-token release, already-approved replies, cleanup, and Raft recovery. Detailed causes such as key_busy, per_key_limit, and global_overload are distinguished in server metrics/logs rather than on the wire.