Regression starting from v14.10.0: "disallowed intents" is not cachable/handlable anymore.

[tabarra]

Which package is this bug report for?

discord.js

Issue description

If you run client.login() specifying privileged intents (like GuildMembers) while the bot doesn't have permission for that, Node will crash due to an unhandled rejection.
Up until v14.9.0, client.login().catch() would be able to catch this error and handle it accordingly, and I have tested and this is still an issue with 14.11.1-dev.1685793842-df8b6e9.0.
A few days ago I talked about it on the DJS discord and a few people acknowledge this issue, but I decided to create the GH issue to keep track of it since this ends up being a breaking issue in my use case where the bot is just one part of my OSS project.

Test output:

• Expected: https://media.discordapp.net/attachments/824411059443204127/1112593310398287933/Code_ZAk80nPgvh.png
• Actual: https://media.discordapp.net/attachments/824411059443204127/1112593310641553488/Code_1PKZOAcfgC.png

Code sample

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

const client = new Client({
    intents: [
        GatewayIntentBits.Guilds,
        GatewayIntentBits.GuildMembers,
    ]
})

client.on('ready', () => {
    console.error('client > ready fired!');
});

client.on('warn', (msg) => {
    console.error('client > warn fired!');
    console.warn(msg);
});
client.on('error', (msg) => {
    console.error('client > error fired!');
    console.error(msg);
});

client.login(process.env.DJS_TOKEN).catch((error) => {
    console.error(`handled login() error: ${error.message}`);
});

Versions

Relevant versions listed above.
This is TS/OS independent.

Issue priority

High (immediate attention needed)

Which partials do you have configured?

Not applicable

Which gateway intents are you subscribing to?

Guilds, GuildMembers

I have tested this issue on a development release

df8b6e9

[Manfred-exe]

I see that issue also at my application

[TylerPlayz424]

same

[tabarra]

Any updates regarding this regression?

[tabarra]

I also noticed some people have the Authentication failed unhandled rejection reason, which leads me to believe the issue is here:
https://github.com/discordjs/discord.js/blob/75d91b52b3ff1ea5ec82b94d1c9c127d9eac3e55/packages/ws/src/ws/WebSocketShard.ts#L666

[didinele]

Yes, albeit this was intended behavior when we made /ws.

Any updates regarding this regression?

I'll fix it when I feel like it if someone else doesn't until then.

[AleeQuintino]

@didinele Please fix this, it's impacting my bot a lot, it shouldn't stop the code but return the error as it was before

[almostSouji]

How does this impact your bot a lot? You should supply intents you have enabled/granted, which is knowledge you should have.

[AleeQuintino]

@almostSouji The big problem is when someone disables the intent or regenerates the token, before it just returned an error and destroyed the section, now it's returning an uncaughtException and stopping all my code.

I need to be able to handle this error, I used a .catch in the .login, but now it's not working anymore

[Jiralite]

The only ones who can disable intents are those you have invited to manage your bot. If they rescind intents your bot needs to work, that seems to be the more pressing issue. Are they seriously rescinding intents all the time on your bot for it to be "impacting my bot a lot"? That seems to be the bigger issue rather than catching the rejection.

[AleeQuintino]

Os únicos que podem desabilitar intents são aqueles que você convidou para gerenciar seu bot. Se eles rescindirem as intenções de seu bot para funcionar, esse parece ser o problema mais urgente. Eles estão rescindindo seriamente as intenções o tempo todo em seu bot para que ele "afete muito meu bot"? Esse parece ser o maior problema, em vez de pegar a rejeição.

I manage custom bots for my clients, I have several clients and some of them are changing permissions and/or resetting the token, and this is stopping my code completely instead of being able to handle this error. In the version prior to 14.10 I was able to handle this error without breaking the code, but I was forced to update to this version and now I can't handle them anymore. What I need is to be able to handle the rejection error without breaking the code

[tabarra]

@almostSouji @Jiralite I think you guys are forgetting that not everybody who uses Discord.js has their own bot.
In my case, the bot is embedded in another (open source, self hosted) project that has discord bot as a side feature, which means I am not the one controlling the bot configuration, and in this scenario is unacceptable for a small configuration issue on a minor side feature to crash the entire project, SPECIALLY since there is literally no downgrade path available as every previous version also doesn't work for some issue (discord api change!? idk).

This is definitely a regression that should be worked on sooner rather than "meh whenever i feel like, but i still will still assign the task to me so nobody else will fix it before"... but that's obviously just my opinion.

[didinele]

This is definitely a regression that should be worked on sooner rather than "meh whenever i feel like, but i still will still assign the task to me so nobody else will fix it before"... but that's obviously just my opinion.

Don't know what assumptions you're running on, but me assigning this to myself isn't very relevant, if anyone else internally wanted to fix it they'd have just asked and taken it, otherwise any regular user of the library is also more than welcome to submit a PR. You are not entitled to my free time.

[tabarra]

You are not entitled to my free time.

Absolutely correct.
But if you don't feel like fixing it right now, why assign this task to yourself right now?

[almostSouji]

You are (as anyone else is) free to propose a pull request at https://github.com/discordjs/discord.js/compare , no matter if the issue is assigned to someone on GitHub or not. This does not necessarily imply that the feature is being worked on next or blocked, but that it is in the expertise and scope of the assigned member.

Since this is getting unnecessarily heated, I'm locking the issue. Feel free to open a PR, if you want this to be fixed rather sooner than later.