Gameplay Action Replay Ledger And Idempotency
The gameplay action replay ledger prevents duplicate client requests from applying duplicate rewards, state changes, or side effects during reconnects and retries.
How It Works
Clients send request IDs. Authoritative gameplay commands wrap durable side effects in an idempotency envelope. The session keeps recent outcomes in a replay ledger and records command metadata for audit and persistence retry.
A repeated request can be replayed when it matches the original command, rejected as a conflicting duplicate when it reuses an ID for different intent, or treated as missing when the server no longer has enough context.
How To Use It
When adding a new gameplay command, define the idempotency key before applying rewards or persistent effects. Make the response replayable without re-running the mutation. Include enough metadata for command audit and retry diagnostics.
For reconnect behavior, assume the client may resend the last accepted request.
Invariants
Request IDs identify client attempts. Idempotency envelopes identify authoritative side effects. Duplicate grants, rewards, currency changes, or quest turn-ins must be impossible even if the client retries after a disconnect.
Debugging
Replayed means the ledger found a matching result. ConflictingDuplicate means a request ID was reused incorrectly. Missing means the server cannot safely replay. Inspect command audit rows, resume records, and persistence retry logs when duplicate behavior crosses reconnect boundaries.