Question
Why does shard state become inconsistent during production restarts?
Kavi Vale
0 reputation · 11 Jul 2020, 21:04 UTC
136.8K views1
Loading…
0 reputation · 11 Jul 2020, 21:04 UTC
When transitioning a discord.js application from a single-process local environment to a production setup using ShardingManager, state inconsistencies frequently emerge. While the bot functions correctly under low-volume local testing, the production environment often experiences issues with missed events or duplicate processing during shard transitions or restarts.
The primary concern centers on how the internal cache and event queue behave when a process is cycled. Without a persistent external store like Redis, the state of a specific shard is lost upon termination, potentially leading to discrepancies between the Gateway's state and the application's memory.
35775 reputation · 11 Jul 2020, 22:55 UTC
When a process running a shard terminates—whether due to a controlled restart or an unexpected crash—all state held within that shard's memory (such as local caches of members, voice connections, or recent event queues) is lost. The ShardingManager handles the process lifecycle but does not provide automatic state recovery from memory. Upon restarting, the shard reconnects to the Discord Gateway, which begins re-synchronizing state, but this synchronization does not perfectly reconstruct the exact in-memory state that existed immediately before the termination, leading to missed or duplicated events.
discordjsdiscord.js mechanism to automatically ensure event continuity across a hard process restart without external aid.The necessary step to ensure continuity is to move critical state to an external, persistent store.
To provide a more precise configuration recommendation, please confirm which version of discord.js is being utilized, as API behavior regarding intents and event handling has evolved significantly between major releases.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 12 Jul 2020, 07:51 UTC
In discord.js v14, ShardingManager keeps each shard's Gateway session ID and last sequence number only in the worker process memory. When the process restarts, that context is gone, so the new shard cannot present a valid RESUME payload. Discord replies with HELLO, starting a fresh session; the in-memory guild, member, and channel caches are empty until refetched, and events missed while the shard was down are not automatically replayed.
To verify, listen for shardDisconnect, shardReady, and raw Gateway opcodes. A RESUME attempt followed by a successful shardReady indicates session restoration; a HELLO after restart confirms the session was lost. This behavior is version-specific to v14 and assumes no external session store is configured.