B · Busy ​

Sent when an acquire request (A) arrived but that key's wait queue had reached the server cap (max_waiters, default 16,384), so it couldn't be queued. The lock simply wasn't obtained — the request itself 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 ​

Do not fail immediately. As long as the wait budget remains, back off and retry (official clients: start at 10ms and double up to 200ms). Once the queue drains, the next attempt enqueues normally. Only if it's still saturated when wait runs out should you report a "busy" error to the caller.

Retries must carry the same owner — that way, if the acquire did go through in the meantime, the server recognizes it as the same acquisition.

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 cap is a memory guardrail, not flow control — it stops an authenticated client from piling up unbounded waiters on a single key and exhausting server memory. It's set well above normal fan-out, so you won't see this response under ordinary conditions. Tune it with max_waiters in the cluster configuration.