Colyseus persistent rewards
Moves confirmed match outcomes from temporary room memory into durable storage. It distinguishes successful, pending and uncertain writes so retries do not duplicate rewards or discard an unfinished result.
colyseus-persistence-rewards
See how it helpsWhen is it useful?
Use it when inventory or rewards must survive room disposal and interrupted database acknowledgements.
What does it help you do?
- Assigns stable identifiers to authoritative match outcomes.
- Separates pending, committed and uncertain persistence results.
- Reconciles interrupted writes before retry or room disposal.
Try asking this
After our cooperative raid, grant each participant one reward identified by the raid result. Simulate storage succeeding but its acknowledgement being lost, then retry and dispose the room. Reconcile the original outcome and show exactly one stored reward per eligible player.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Colyseus — persistence rewards
Use when persisting Colyseus match results, inventory or rewards outside room memory.
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
Assign a stable match/outcome identifier and separate pending, committed and unknown outcomes. Validate results from authoritative state and make durable writes idempotent. Reconcile an interrupted write before retrying; keep room disposal from silently dropping an uncommitted outcome.
Deliver
A persistence/outcome contract with retry and reconciliation behavior. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
A successful room broadcast does not prove a database commit; never reward twice after an uncertain response.
Acceptance scenario
Interrupt after persistence but before acknowledgement, retry with the same outcome ID and confirm exactly one durable reward. 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