Individual shards not respawning upon death

[cycloptux]

Hey, since updating to 12.4.0 (and then tested on master as well) from 12.3.1 on a sharded bot (2 shards, ~1000 servers per shard) I noticed individual shards are not always respawning when it comes to certain errors (e.g. SIGABRT or SIGSEGV caused by out of memory errors, but this list might be partial).

Reverting back to 12.3.1 restores the automatic respawn.

You can test this by spawning a simple bot with 2 shards and then forcing a memory leak with:

const test = [];
if (client.shard.ids[0] === 1) for (let i = 0; i < 1e10; i += 1) test.push(Math.random());

Behavior on 12.3.1 (my custom logs, ymmv):

[ShardingManager] [Shard 1] Child process [ 11126 ] closed with signal code [ SIGABRT ] and exit code [ null ]. Killed? [ false ].
[ShardingManager] [Shard 1] Spawned child process with PID [ 11143 ].

Behavior on 12.4.0 and master:

[ShardingManager] [Shard 1] Child process [ 11329 ] closed with signal code [ SIGABRT ] and exit code [ null ]. Killed? [ false ].

For this last case, the shard respawn is never triggered (last downtime lasted ~7 hours before I could restart the process).

Manually triggering shard.respawn() on the "death" event cases the shard to spam the "death" event N times, and then respawning N processes.
manager.respawn is correctly set to true in both cases.

Further details:

• discord.js version: 12.4.0 / master

• Node.js version: 12.19.0

• Operating system: Amazon Linux 2 (CentOS), Ubuntu 18.04

• Priority this issue should have – please be realistic and elaborate if possible: High (only for sharded bots), could not find a workaround other than restarting the whole process.

• I have also tested the issue on latest master, commit hash: 250c3ae3c1f025c092383e4661bbb386e89a3c23

[Koyamie]

I can confirm that this issue exists, I also have it with the same version.
Error [SHARDING_NO_CHILD_EXISTS]: Shard 218 has no active process or worker.
Happening very frequently.

[MattIPv4]

Having a look at this, if I run my bot using a local clone of discord.js, with console.log(respawn, this.manager.respawn); added to the start of

discord.js/src/sharding/Shard.js

Lines 376 to 391 in 7ec0bd9

	_handleExit(respawn = this.manager.respawn) {
	/**
	* Emitted upon the shard's child process/worker exiting.
	* @event Shard#death
	* @param {ChildProcess|Worker} process Child process/worker that exited
	*/
	this.emit('death', this.process || this.worker);
	this.ready = false;
	this.process = null;
	this.worker = null;
	this._evals.clear();
	this._fetches.clear();
	if (respawn) this.spawn().catch(err => this.emit('error', err));
	}

I get the following:

Eval'ing process.exit() in a shard: 0 true
Eval'ing process.abort() in a shard: null true

[MattIPv4]

Looks like this is a regression caused by https://github.com/discordjs/discord.js/pull/4845/files#diff-75a4f785c550209a707697c399a87938fad288bbd1c571614808ed8c08edbd04L99 -- event arguments are now being passed to handleExit when they shouldn't be