Table Recovery and Safe Releases
Reconnects, crash recovery and planned handoff have different guarantees. Why ongoing human-only tables still block game-runtime releases.
Recovering a room and its chips is different from resuming an unfinished hand exactly. BluffKing separates reconnects, crash recovery and planned release handoffs. Ongoing human-only tables currently block backend and H5 releases.
What a reconnect restores
If a browser disconnects while the server process survives, the original session actor still owns the game. After identity and seat checks, the player receives the current snapshot and authorized hole-card delivery, returning to that game.
Reconnecting does not grant a fresh decision clock. The current deadline still applies. Timeouts and other players’ actions during the disconnection are not undone by refreshing the page.
What a restart restores
Once the process disappears, its memory is no longer available. Ordinary crash recovery loads room configuration, the original expiry and the last committed recovery checkpoint from the database. For Hold’em:
| Durable state that can be restored | Not promised by the ordinary checkpoint |
|---|---|
| Seat ownership, stacks, cumulative buy-ins, pending top-ups and seat lifecycle | An unfinished hand’s hole cards, board, current pot and complete engine state |
| Completed-hand count, last completed hand, dealer position and relevant blind progression | That hand’s dealing seed, actor and exact decision timer |
This is a card-free recovery baseline. Buy-ins advance it; bets within the current hand do not update it action by action. A crash abandons the unfinished hand and restores the durable boundary, rather than inventing a replacement card to continue. Completed hands have separate replay records; replay data is not a running-state snapshot for every instant.
Queue admission is also different from database commit. Required writes run in table order, and completed hands, related records and recovery checkpoints are saved transactionally. Ordinary operation still has a window after enqueueing and before commit. A sudden interruption can rely only on committed data; every result just displayed to a player cannot be assumed to have reached durable storage.
What planned releases already support
A controlled handoff already exists. For supported Hold’em tables, the predecessor lets the current hand finish naturally, saves additional continuity state between hands, flushes the checkpoint and parks. Release control checks that required writes have drained and checkpoint revisions agree. The candidate validates the archives and restores tables before opening admission.
This can preserve time-bank usage, chat and the previous result beyond the ordinary crash checkpoint. It requires both runtimes to follow the protocol, a supported table state and the full validation sequence. Unsupported Hold’em states, including advanced encrypted dealing and squid, reject handoff. Arbitrary process or host crashes are outside this guarantee. Direct-hotfix checkpoint takeover does not replace the complete planned-handoff proof either.
Why human-only tables still block releases
Preparing a ready candidate addresses service availability. Preserving the hand, accounting, action order and clocks addresses game integrity. An answering HTTP endpoint or a successful reconnect does not establish the latter.
This is not fundamentally impossible. Existing handoff solves part of the problem, but does not promise lossless migration for every mode, unfinished-hand state and failure point. Current policy therefore avoids deliberately interrupting ongoing human-only tables rather than exposing players to those remaining boundaries.
Relaxing that policy would require a defined mode and version scope, with evidence for safe-boundary waiting, drained writes, exclusive runtime ownership, card secrecy, clock continuity and failure recovery. Existing handoff provides a foundation. Removing the occupancy check alone would not establish those guarantees.
Which rooms block a release
The authoritative metric, human_only_tables, counts tables that are started, have seated humans and have no bots. It is not the online-user count or total-room count. Waiting rooms and tables containing bots do not count toward this metric; their exclusion does not mean releases cannot affect them.
A Hold’em table’s started flag remains set after it has dealt a hand; the interval between hands does not turn it back into an unstarted waiting room. “This hand just finished” therefore cannot substitute for a zero count or justify bypassing the guard.
A nonzero count stops game-runtime release. An unreadable result cannot be treated as zero. Checks repeat before production mutation and cutover, including hotfixes and H5-only releases.
The marketing website has a separate static publishing path that replaces neither backend nor H5, so it is exempt from this occupancy gate. A proxy reload may still cause one reconnect, but it returns to the same unchanged backend holding the game state.
Source entry points: server/src/runtime_checkpoint.rs, server/src/session_persistence.rs, server/src/session/actor/boundary.rs, server/src/release_handoff.rs and server/src/handlers/admin_tables.rs. These describe current boundaries, not a promise of lossless continuation after every failure.
Cooler Hands and Dealing · Release Identity and Version Checks