1 realtime client reconnect journal and command replay
forgejo-actions edited this page 2026-07-13 19:45:35 +00:00

Realtime Client Reconnect Journal And Command Replay

The realtime client reconnect journal decides which outbound commands are retained, merged, replayed, or dropped while the transport reconnects.

How It Works

Client commands are classified by delivery lane and reconnect replay policy. Control, reliable gameplay, movement, background, and cosmetic datagram traffic have different retention and coalescing behavior. Gameplay actions with durable request ids can replay; non-replayable or stale traffic is denied or dropped.

The transport doctor ledger records reconnect and drop decisions so runtime diagnostics can explain what happened.

How To Use It

When adding a new outbound packet, choose its reconnect replay policy before wiring UI or gameplay code. Decide whether it can coalesce, whether only the latest value matters, and whether replay would duplicate durable side effects.

Use reconnect tests for queue rollover, gameplay action retention, reconnect grace, and wake-channel closure.

Invariants

Durable gameplay actions must not apply twice. Movement batches can be coalesced when newer input supersedes older input. Cosmetic datagrams can be dropped. Reconnect grace must bound how long the client buffers traffic.

Debugging

Look for reconnect grace expiry, lane capacity drops, replay denied events, closed transport wake channels, and doctor ledger rows. If an action disappears after reconnect, check whether its delivery contract was replayable.

Examples

A quest turn-in request should replay by durable request id and receive the same authoritative result. A cosmetic gameplay-state datagram should normally keep only the newest state or drop if the lane is full.