feat: Add message to send resume event to shard

[GrapeColor]

Please describe the changes this PR makes and why it should be merged:
After a shard reconnects, the Shard#ready flag remains false because the ready event is not fired.
This PR solves this by firing Events#ShardReady when WebSocketShard#Ready fires.

Status and versioning classification:

• I know how to update typings and have done so, or typings don't need updating

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
discord-js	❌ Failed (Inspect)			Jun 14, 2023 11:41am

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
discord-js-guide	⬜️ Ignored (Inspect)			Jun 14, 2023 11:41am

[Qjuh]

This would make the Client#shardReady event emit as soon as the Gateway READY payload is received. This is not what the prior implementation did, this event is meant to be emitted when all Guild payloads did arrive or the guildTimeout was reached.

So this is a breaking change that should not be merged.

But I would like to know what issue there actually was that needed this fix in your eyes. Can you please open a Issue here on GitHub with reproducible code that shows what needs fixing? Because in the current implementation the Client#shardReady should be emitted once all Guild payloads were received or the timeout to wait for unavailable Guilds ended. Because it’s the same code that does this successfully on first login call that also is responsible for this on reconnect.

[GrapeColor]

I understood the problem and fixed the change.
However, it seems that the intention of the problem is not conveyed, so I will open an issue.

[Qjuh]

Okay, now I see what you‘re getting at. #9474 introduced this issue by listening to ShardReconnecting and ShardDisconnecting event and setting ready to false in those cases.

Solving this by emitting a ShardReady event in places it wasn’t emitted before is still a breaking change, because other code listening to that event will now also be called on resume while it wasn’t before.

I‘ll have a look at this issue later to see how this could be fixed in a non-breaking way.
Looks like the better approach here might be to listen to Client#shardResume in ShardClientUtils.js and send a _resumed message to the ShardingManager process. In Shard.js this message should then be handled in _handleMessage and set this.ready = true; without emitting the Shard#ready event.

[GrapeColor]

Thank you for showing me your approach.
I'll try it that way.

[GrapeColor]

I have finished fixing the changes.
Request a review.

[Qjuh]

That does indeed look good now. Did you test that it actually solves your initial issue too?

[GrapeColor]

Did you test that it actually solves your initial issue too?

I have confirmed that the ready flag becomes true after a shard resumes.
So the initial issue is solved.

[GrapeColor]

I verified with the following code.

Code of the bot to be sharded:

import { Client, Events } from 'discord.js';

const client = new Client({ intents: ['Guilds'] });

client.on(Events.Debug, (message) => console.log(message));

client.login()
	.catch(console.error);

Code to shard the bot:

import { ShardEvents, ShardingManager } from 'discord.js';

const manager = new ShardingManager('./bot.js', {
	token: 'YOUR_TOKEN',
	totalShards: 10,
});

manager.on('shardCreate', (shard) => {
	shard
		.on(ShardEvents.Ready, () => console.log(`Shard #${shard.id} turns ready.`))
		.on(ShardEvents.Reconnecting, () => console.log(`Shard #${shard.id} is attempting to reconnect or re-identify.`))

	setInterval(() => console.log(`Shard #${shard.id} is ${shard.ready ? '' : 'not '}ready.`), 60_000);
});

manager.spawn({ timeout: -1 })
	.catch(console.error);

---

Below is an excerpt of the log before and after the change.

Before:

Shard #1 is ready
Shard #1 is ready
Shard #1 is ready
[WS => Shard 1] The gateway closed with an unexpected code 1006, attempting to resume.
Shard #1 is attempting to reconnect or re-identify.
[WS => Shard 1] Destroying shard
[WS => Shard 1] Connection status during destroy
[WS => Shard 1] Connecting to wss://gateway-us-east1-b.discord.gg?v=10&encoding=json
[WS => Shard 1] Waiting for event hello for 60000ms
[WS => Shard 1] Preparing first heartbeat of the connection with a jitter of 0.371327938827104; waiting 15317ms
[WS => Shard 1] Resuming session
[WS => Shard 1] Resumed and replayed 1 events
Shard #1 is not ready
[WS => Shard 1] First heartbeat sent, starting to beat every 41250ms
Shard #1 is not ready
Shard #1 is not ready
Shard #1 is not ready

After:

Shard #2 is ready.
Shard #2 is ready.
Shard #2 is ready.
[WS => Shard 2] Destroying shard
[WS => Shard 2] Connection status during destroy
Shard #2 is attempting to reconnect or re-identify.
[WS => Shard 2] Connecting to wss://gateway-us-east1-d.discord.gg?v=10&encoding=json
[WS => Shard 2] Waiting for event hello for 60000ms
[WS => Shard 2] Preparing first heartbeat of the connection with a jitter of 0.7769187774516333; waiting 32047ms
[WS => Shard 2] Resuming session
[WS => Shard 2] Resumed and replayed 1 events
Shard #2 is ready.
[WS => Shard 2] First heartbeat sent, starting to beat every 41250ms
Shard #2 is ready.
Shard #2 is ready.
Shard #2 is ready.