Video Room Lifecycles: Debugging Accumulating Empty Sessions Without Presence Drift

Short answer: delete a video room from the active index only after authoritative occupancy reaches zero, stays there for a measured grace period, and still belongs to the generation that scheduled cleanup. A last-participant leave callback is a hint, not proof: disconnects race with reconnects, callbacks can be duplicated or reordered, and one server rarely owns every relevant state transition. For a B2B shared workspace, optimize for accurate presence first. Cleanup latency comes second. Choice Presence accuracy Failure behavior Operational load Delete inside the leave handler Low under retries and reconnects One missed event leaves a ghost; one early event removes a live room Low until debugging starts Grace timer plus authoritative recount High when the count comes from the room authority Duplicate signals converge on the same result Moderate Periodic full sweep only Eventually accurate Ghost rooms remain until the next sweep Predictable but potentially heavy Recommendation: use a generation-checked grace timer after any possible transition to zero, then retain a slow reconciliation sweep as a backstop. The timer protects reconnects. The generation check protects newer occupants. The sweep repairs missed signals. How should you debug accumulating empty video rooms? WebRTC defines peer connections and their state, but it does not define the lifecycle of your application-level room. A connectionState change describes one peer connection. It cannot tell a Node.js process that every participant, on every device and server, has permanently left a workspace room. That boundary matters. Suppose account acme-design has room weekly-review. Priya closes a laptop while a phone reconnects through another signaling node. The old node observes a departure first. If it deletes the room immediately, the workspace briefly reports nobody online even though the phone session is becoming active. Presence accuracy loses to callback timing. The reverse failure is quieter. A process restarts after removing the final member from memory but before enqueueing deletion. No future leave event exists to retry the work. The empty room survives in the active index and keeps appearing in debug cleanup reports. Treat events as triggers to verify state, not state itself. This is the key distinction. Callbacks lie. The two criteria that settle the design The first criterion is authority. Ask which component can answer, at decision time, how many valid participant leases exist for a room. That might be one transactional data store, a single room owner, or a consensus-backed registry. A count assembled independently from each Node.js worker is not authoritative if workers can restart or lose messages. The second criterion is race containment. Cleanup must prove that the empty observation still belongs to the current room generation. A plain timer captures stale intent: it may fire after someone has joined. A generation token turns that timer into a conditional operation. Joining increments the generation. Cleanup reads occupancy and deletes only if both occupancy is zero and the generation still matches the one that scheduled the check. Stale intent wins unless the delete is conditional. Pick a grace interval from measured reconnect behavior, then expose it as one service-level setting. Do not create a maze of per-room switches. Measure the distribution from disconnect signal to restored authoritative lease, choose an acceptable false-offline risk, and validate it under packet loss and process restarts. There is no defensible universal number in the WebRTC specification. I would benchmark three paths separately: event-to-empty-observation latency, reconnect-to-visible-presence latency, and sweep duration at the largest expected room count. Those measurements answer different questions. Folding them into one average hides the exact race being debugged. A small state machine beats callback glue The useful states are active, suspectEmpty, and absent. Keep the transition code narrow. Every leave, lease expiry, and transport-close signal may schedule the same idempotent verifier; none may delete directly. type RoomSnapshot = { roomId: string; generation: number; activeLeases: number; }; interface RoomStore { read(roomId: string): Promise; deleteIfEmpty(roomId: string, generation: number): Promise; listSuspectEmpty(before: Date): AsyncIterable; } const GRACE_MS = 15_000; function scheduleEmptyCheck( store: RoomStore, roomId: string, observedGeneration: number, ): void { setTimeout(async () => { const current = await store.read(roomId); if (!current) return; if (current.generation !== observedGeneration) return; if (current.activeLeases !== 0) return; await store.deleteIfEmpty(roomId, observedGeneration); }, GRACE_MS); } async function reconcileEmptyRooms( store: RoomStore, olderThan: Date, ): Promise { for await (const roomId of store.listSuspectEmpty(olderThan)) { const current = await store.read(roomId); if (!current || current.activeLeases !== 0) continue; await store.deleteIfEmpty(roomId, current.generation); } } The sample depends on deleteIfEmpty being atomic. In a relational store, implement it as a conditional delete inside the same consistency boundary as lease updates. In an actor-style room owner, serialize joins, leaves, and deletion through that owner. The interface is intentionally boring. Good DX here means one cleanup primitive, not six callbacks with slightly different rules. The fixed 15_000 milliseconds is an example, not a recommended default. Benchmark your clients before choosing it. Also add jitter to bulk reconciliation scheduling in a real deployment so every worker does not scan at once. The trade-off is real: the grace window intentionally retains an empty record longer, the authoritative read adds storage traffic, and the sweep consumes capacity even when event delivery is healthy. This design is a poor fit when a room owner already serializes every membership transition or when delayed cleanup has no user-visible consequence. Tests should force the ugly interleavings: leave, join, old timer fires; duplicate leave; worker stops before scheduling; lease expires without a close signal; and two reconcilers attempt deletion. Assert visible workspace presence as well as database rows. A clean table with a wrong online indicator is still a failed system. Instrument suspect_empty_age, conditional-delete outcomes, active leases at verification, and room generation mismatches. The generation-mismatch counter is especially useful: it shows how often the grace check prevented a stale deletion. Alert on the age of the oldest suspect room, not merely the number of rooms, because normal call churn can make raw counts noisy. When is the simpler runner-up better? A periodic sweep alone can be the better choice for an internal tool where presence may lag and room volume is small. It has fewer moving parts, and its worst-case cleanup delay is easy to state: roughly the sweep interval plus execution time. Use bounded batches and a cursor so one large scan does not monopolize the store. Immediate deletion can also be correct, but only when a single authoritative room owner serializes membership changes and reconnects create a new room identity rather than reuse the old one. That contract is stricter than most shared-workspace products want. Write it down before relying on it. For user-facing B2B presence, the combined design earns its extra mechanism. The decision rule is compact: if an incorrect offline indicator is worse than retaining an empty room for one grace window, verify after a delay and guard the delete with the observed generation. The limitation is extra state, reads, and background work; teams that cannot operate those pieces should accept slower cleanup and use the bounded sweep alone. Keep reconciliation anyway. Events get lost. Sources References: W3C WebRTC 1.0: https://www.w3.org/TR/webrtc/