/receive lets more than one consumer long-poll on the same token at once. Nothing stops a leftover watcher process and a freshly relaunched one from polling in parallel, so the queue interleaves between the two connections instead of going to a single listener. This mostly bites the bridge/watcher setup, where a relaunch can briefly overlap with the old process before it exits.
Sketch: give each long-poll a lease id. A second poll on the same token while a lease is held gets rejected with 409 already_listening, except a newer lease always wins, so a relaunch never locks itself out waiting on a dead process's lease.
Needs a PROTOCOL_VERSION bump, since it changes /receive's behavior for connected bridges.
/receive lets more than one consumer long-poll on the same token at once. Nothing stops a leftover watcher process and a freshly relaunched one from polling in parallel, so the queue interleaves between the two connections instead of going to a single listener. This mostly bites the bridge/watcher setup, where a relaunch can briefly overlap with the old process before it exits.
Sketch: give each long-poll a lease id. A second poll on the same token while a lease is held gets rejected with 409 already_listening, except a newer lease always wins, so a relaunch never locks itself out waiting on a dead process's lease.
Needs a PROTOCOL_VERSION bump, since it changes /receive's behavior for connected bridges.