Closed hackermondev closed 2 years ago
It doesn't "fail", it waits for the ratelimit and will eventually connect. This is intended default behavior. If you would like for it to throw, you can use the rejectOnRateLimit
REST option.
It doesn't "fail", it waits for the ratelimit and will eventually connect. This is intended default behavior. If you would like for it to throw, you can use the
rejectOnRateLimit
REST option.
@didinele It doesn't wait though. It exists the program immediately (check my attached GIF) And shouldn't it at least log something to debug (v13 did)? It doesn't do that either.
It doesn't wait though. It exists the program immediately (check my attached GIF)
Unfortunately, I have never seen this behavior on any version of v14 (and we see people ask about this every so often in support), nor am I able to attempt it without getting myself CF banned on purpose, which I'd rather not, but looking at the source code, the behavior you're describing seems almost certainly impossible - which would make this an issue on your end one way or another.
The call to /gateway/bot is done here: https://github.com/discordjs/discord.js/blob/4f3c13628ecaf8d22174a7a1e227bb7b8278dbb5/packages/discord.js/src/client/websocket/WebSocketManager.js#L134-L141
And the error is funneled here: https://github.com/discordjs/discord.js/blob/4f3c13628ecaf8d22174a7a1e227bb7b8278dbb5/packages/discord.js/src/client/Client.js#L231-L237
Notice how if an error was encountered, we do just outright throw it, but in the case of any 429 the request is just re-queued:
And shouldn't it at least log something to debug (v13 did)? It doesn't do that either.
No, it's outside of the core library's space. If you want debug logs, listen to them from <Client>#rest
Experienced the same issue here https://github.com/discordjs/discord.js/issues/8623
@didinele I did some digging and I found what was causing the issue.
This line basically is telling the program to wait for the ratelimit to finish. The ref
option is set to true
and that is what is causing the issue.
If we look back at node documentation (https://nodejs.org/api/timers.html#timerspromisessetintervaldelay-value-options), we can see what the ref
option does.
ref
Set to false
to indicate that the scheduled Timeout between iterations should not require the Node.js event loop to remain active. Default:true
.
So, what is happening is that the timeouts don't require the event loop to remain active and then because there's nothing else going on (no open gateway connection), the program exists and the timeout doesn't correctly work.
I've went ahead and created a pull request to fix this: #8779
Which package is this bug report for?
discord.js
Issue description
Discord.js v14 silents fails if initial gateway connection API endpoint (
/api/v9/gateway/bot
) is ratelimited.Steps to reproduce:
Expected Result: It should throw an error or print something to the console Actual Result: the issue here is that discord.js doesn't return anything to the user and the program just ends abruptly. Note: On discord.js v13, it doesn't print anything to the console either (unless you're logging
debug
events) but it waits out the timeout. Right now, djs v14 doesn't debug anything and it doesn't print anything to the console when its ratelimited (it just closes the program)GIF EXAMPLE:
Code sample
Package version
14.6.0
Node.js version
16.15.0
Operating system
Linux
Priority this issue should have
Low (slightly annoying)
Which partials do you have configured?
No Partials
Which gateway intents are you subscribing to?
Guilds, GuildMembers, GuildMessages, MessageContent
I have tested this issue on a development release
No response