Colyseus reconnection
Gives disconnected players a defined time to return without keeping seats forever. It separates accidental network loss from leaving and restores the server’s current state rather than duplicating the player.
colyseus-reconnection-seats
See how it helpsWhen is it useful?
Use it when mobile network loss, client restart or deliberate departure need different room behavior.
What does it help you do?
- Distinguishes transport loss from deliberate departure.
- Defines bounded seat retention and token expiration.
- Restores authoritative snapshots without duplicating player state.
Try asking this
In our turn-based tactics match, disconnect a player during their turn and reconnect before the reservation expires. Repeat after expiration and after a deliberate leave. Preserve the correct turn and unit ownership, reject stale return tokens and never create a second copy of the player.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Colyseus — reconnection seats
Use when implementing Colyseus disconnect, reconnection tokens, seat retention or late join.
Version and project gate
Inspect Server, client SDK and @colyseus/schema versions, TypeScript/decorator configuration, room registrations, auth hooks, patch/simulation rates, transport, deployment topology and persistence adapters. The 0.17 reconnection lifecycle must not be assumed for older versions. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Identify the installed drop/leave APIs. Define disconnected, reconnecting, rejoined and expired states and bounded seat lifetime. Separate transport loss from a deliberate leave. Resume from the authoritative snapshot and refresh tokens at the documented point; do not log tokens.
Deliver
A reconnection state table and matching server/client behavior with an explicit expiry outcome. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
Do not remove resumable player state on every transport drop or assume reconnect preserves a client object across every SDK version.
Acceptance scenario
Drop the network during play, restart the client, expire the seat and try reusing an invalid token without duplicating a player. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Relay. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Included files 1
SKILL.md