Disconnecting holders need automatic control reclaim

What it is

When the holder of control goes offline (network drop, client crash, walking away), the control seat cannot vanish with them — an automatic reclaim rule must detect the disconnect and return control to an assignable state. Without it, a single-operator seat gets held indefinitely by an absent party: everyone can see the object but nobody can operate it, and the whole shared activity freezes in the grip of a ghost holder. Disconnect reclaim is structurally the same problem as timeout release for content locks (exclusivity must lift itself when the holder is absent) but guards a different asset: one protects editing rights, the other operating rights.

Why it happens

Disconnect detection carries decision latency: the network layer cannot instantly tell "gone" from "jittering," and can only rule via timeout (no heartbeat for N seconds means dead). Reclaim rules therefore necessarily balance two errors — too short a wait, and one jitter kicks a mid-operation holder off the seat (false kill); too long, and the seat idles during the outage while everyone waits (missed kill). The rule must thus specify three things: the detection signal (session-layer heartbeat or keep-alive, not application-layer input — a person may simply be pausing, not gone); the reclaim destination (back to the chair, into a pool for application, or auto-assigned to the next in queue — different destinations reshape the power structure); and re-entry handling (does the original holder auto-resume on reconnect or re-queue — auto-resume is jitter-friendly, re-queuing protects others from oscillation torture). The state of the operated object at the disconnect moment also needs an account: how half-finished input is marked, and where the successor can see "the last valid operation stopped here."

Where it stops holding

Automatic reclaim should target only involuntary absence. A holder who exits deliberately (clean close, explicit leave) should release immediately through the normal handover flow, with no timeout wait. Reclaim rules also cannot handle "present but not operating" — that is idle holding, which needs an idle timeout, not a disconnect check; the two use different signals (input activity versus connection liveness), and conflating them misjudges a long-thinking operator as disconnected. In multi-seat settings (several people each holding control of different objects), reclamation must proceed per seat — one network partition must not trigger a global seat wipe.

Applying it

• Use session-layer heartbeats for disconnect detection with timeouts tuned to the network context (30–60 seconds for consumer networks), and separate the two paths: "deliberate exit releases immediately" and "disconnect reclaims after timeout."
• Make the reclaim destination explicit and announce it to the group: the seat returns to the chair or to the pool, and the holder display updates to "unassigned" immediately.
• On the original holder's return, offer the choice: resume the seat (if unclaimed) or queue (if taken), with a view of what happened during the outage.
• Mark "the previous holder's last valid operation, position and time" in the successor's interface.
• Verification: simulate three interruption types — pulling the cable, crashing the client, merely backgrounding without input — and check that only the first two trigger reclaim and the third does not; then verify the reconnect path and the completeness of operation markers from the outage window.

Related

• Same group: V3.05.1 Scenarios allowing only one operator at a time need explicit control attribution · V3.05.2 Control handover needs request and grant as two independent actions · V3.05.3 The current holder of control must be persistently visible · V3.05.5 Forced seizure of control must leave a traceable record
• Nearby: V3.03.2 Forgotten locks block everyone else · V3.03.3 Locks need timeout and forced release
• Search terms: disconnect recovery · floor reclaim · session timeout · presence heartbeat