A resilient casino game session treats a timeout as an unknown result, not as a failed round. The client retries or queries with the same command identity, the server returns one authoritative status, and the interface restores, completes, voids or explains the round according to a tested interruption policy.
This distinction prevents the most dangerous retry failure: the first request succeeds but its response is lost, then an automatic second request creates another wager. Network recovery is therefore a domain protocol, not a spinner wrapped around fetch().
Give every player command a stable identity
Before sending an action that can create a round or move value, the client generates a unique command identifier. It persists that identifier with the intended action until the server returns a terminal or explicitly recoverable status. A retry carries the same identifier and identical semantic payload.
The server stores the identifier and result atomically with accepting the command. If the same key arrives again, it returns the recorded status or response. If the key arrives with a different payload, it rejects the conflict rather than guessing which action the player meant.
HTTP alone does not provide this behavior for an ordinary POST. RFC 9110 defines idempotent methods and notes that a client should not automatically retry a non-idempotent request unless it knows the request semantics are idempotent or can detect that the original was not applied. The application contract supplies that knowledge for a round command.
Persist acceptance before performing dependent work
The server-side boundary must be atomic enough that a crash cannot leave an accepted wager without a recoverable identity. Depending on the architecture, that can mean one database transaction, a transactional outbox or another durable state-and-event pattern.
Return statuses that describe domain truth: not found, received, accepted, pending, committed, settled, voided or rejected. Avoid treating a gateway 500 as the round status; it only says that one response path failed. The client should query the authoritative round endpoint with its original identity after an ambiguous transport error.
Keep balance changes connected to the same domain transaction or durable workflow. A round cannot be considered recovered merely because its animation resumes while wallet settlement remains unknown.
Resume from authoritative state, not client animation
The browser can cache presentation state to improve continuity, but the RGS owns the authoritative round. On reconnect, the client authenticates the session, sends the last known round and command references and asks for current status. It then maps that status into a defined presentation path.
If the outcome is committed, present the recorded result and current authoritative balance. If the round is a stateful multi-step game, restore the permitted decision state and remaining actions. If the wager was never accepted or was voided, explain that state clearly and allow a new action only after the previous key is terminal.
Do not replay a celebration by blindly re-running the original request. Rendering should consume restored state, not produce it. Keep the outcome, balance and next actions clear even if the full animation asset is no longer available after a long disconnection.
Design interruption messages as part of the protocol
Player messaging should distinguish “connecting,” “checking round status,” “round completed,” “round restored” and “round voided.” A generic “something went wrong” followed by an enabled spin button can invite a duplicate action while the first is still pending.
The interruption policy must match applicable market requirements. For Great Britain, RTS 10 describes fair handling of interruptions, restoration for stateful games and retention of sufficient recovery information within its stated scope. It also requires operators to make information about interruption policies available. Other jurisdictions may require different behavior.
Place a concise policy entry in rules or help, and make the live message name what is known without claiming a wager failed merely because the response did not arrive.
Test every ambiguous network boundary
Fault injection should disconnect the client before a request leaves, after partial transmission, after server acceptance, after outcome commitment, during wallet settlement and while the response returns. Each case should be run with a retry, page reload, browser backgrounding and a second active tab where those states are supported.
Assert invariants, not only screens: one accepted round per command key, no duplicate debit, one final outcome, balance consistency, a recoverable state and a complete audit trail. Reintroduce a duplicate-creation defect and confirm the test fails before relying on the gate.
Operational telemetry should count duplicate attempts, status-query outcomes, rounds pending beyond the objective, successful restoration and conflicts. The RGS observability guide explains how to connect those metrics to traces without using round or player IDs as unbounded metric labels. The deterministic replay guide provides an isolated path for incidents that require reconstruction.
Expire keys only after the risk window closes
Idempotency records need a retention rule longer than every permitted client retry and recovery window. If a key disappears while an old client can still retry, the server can mistake the same action for a new one. Align expiry with session, dispute, audit and market requirements rather than choosing a short cache duration for convenience.
For casino game development, the recovery contract should be designed with the round protocol before animation and error copy. A trustworthy reconnect is visible in the architecture: stable identity, durable state, explicit status, safe presentation and evidence at every boundary.
Frequently asked questions
What is a resilient casino game session?
A resilient session preserves a fair, understandable game state through temporary network, browser or service interruption. The client can ask for authoritative status and resume, complete, void or explain the round according to the platform policy.
What is an idempotency key for a game round?
An idempotency key is a unique client command identifier that lets the server recognize a retry of the same intended action and return the original status instead of creating a second round or wager.
Is an HTTP POST request automatically idempotent?
No. HTTP defines POST as non-idempotent by default. An application can implement idempotent command semantics with a unique key, atomic persistence and a stored response or status.
What should the game show after reconnecting?
The game should show the authoritative round status and current balance, then either restore the last valid state, present the completed result, explain a void or invite a safe retry. It should not infer success from a missing response.
Can the client decide that a timed-out round failed?
No. A timeout means the client does not know the result. The server may have accepted and committed the action, so the client must query authoritative status using the original command or round reference.
How should reconnect behavior be tested?
Inject disconnects before send, during transmission, after acceptance, after outcome commitment and during response delivery. Verify duplicate suppression, balance consistency, state restoration and player messaging at every boundary.
