Authentication failed at WebSocketShard.onClose
I get this error once every few weeks and discord resets my bot's token.
It appears your bot, Booster Bot, has connected to Discord more than 1000 times within a short time period. Since this kind of behavior is usually a result of a bug we have gone ahead and reset your bot's token.Unfortunately I don't have full stack trace, can somone help with potential issue for this? I'm using djs v14.11.0
20 Replies
- What's your exact discord.js
npm list discord.js and node node -v version?
- Not a discord.js issue? Check out #other-js-ts.
- Consider reading #how-to-get-help to improve your question!
- Explain what exactly your issue is.
- Post the full error stack trace, not just the top part!
- Show your code!
- Issue solved? Press the button!Also, please ping when reply, thanks.
You need to work/improve on whatever is causing your bot process to crash constantly so Discord doesn't revoke your token again and again.
Because it sounds like your bot is on a restart loop and logging into API a thousand times.
Thanks for the reply but I did not see any crash logs. I can only see
Authentication failed logs means application was failing to come up?
If it was crashing there would have been logs in b/w these failures.
It was a 504 from top.gg api but that's not rate and it's handled properly
api to post bot's guild & shard count
The log file is only manually cleaned.. I had all the logs. Did not see any error that has not happened before and may cause bot to restart.
Even if bot restarts, I get some logs like db connection created etc.. but I'm considering that they might be missing cuz process might not restart but somehow bot login got triggered.
I'm suspecting that I have ~9gb memory allocated for bot and js gc was failing to clean old objects maintained by djs so somehow new objects required for connection are not being created?
When I was restarting the bot process was still taking 9gb memory which is weird as bot was technically offline but heap memory was still utilised.
@Qjuh The same thing happened today, but again, no logs that can even hint a restart š¢
I found a similar issue reported here - https://github.com/discordjs/discord.js/issues/9843
GitHub
"connected to Discord more than 1000 times within a short time peri...
Which application is this bug report for? Documentation Issue description Greetings! We just experienced something really weird in our discord bot at the date 6th of September, when we just got an ...
This time I found these application logs -
Also found this log in between spam on
Authentication failed messages:
Something wrong on your code
It was ~9gb it's allowed to go to 12gb
there were some spikes in cpu at that time (bot went off at 7:45)
I'm thinking of
ERR_INTERNAL_ASSERTION node error arrised from djs lib which caused readyState 0 and then an infinite loop of logins?
I have logs on read event but I did not get any logs means internal login was failing and login on discord were getting successful
I'll try to update the node version, will let you know if this happens again as I'm not able to reproduce the issue
@Qjuh I upgraded node version to
v20.11.1 but still got this error and token got reset after 1000 login attempts.
Again, I did not got any success log on ready event means lib internally was trying and failing :/
only 1 log (that is after I restart the bot after token got reset)
I have 2 processes running, main bot and a worker process.
I enqueue some events to a redis queue that is consumed by worker & process thing, to offload some heavy tasks from main thread
same error was on main bot tho last time
yes both are independent nodejs process with independent ws connections
I have these queues.. messages/events in some queues are from ws like boost added or boost removed and some are scheduled events like enqueue voteReminder event after 12h (redis will enqueue event after 12h in the queue) and I have consumer listening for new events in worker process
I'm using
bull library for this
I did not tell this before because it did not seem relevant to the error since both ws connections are independent
FWIW I am also running into this as of a few days ago. Haven't changed anything with my bot in over a year, so realistically it's not a regression in DJS (if it's even the same problem we're talking about, this could kinda be anything)
I know my bot crashes from hitting the RAM ceiling and restarts with pm2, but not more than once every 10 minutes or so (which is still a LOT, but not 1000+ in "a short time period")
So maybe Discord lowered the login attempt ceiling recently
Actually my error is probably just different than this, your error is not clearly relating to a pm2 & ever growing RAM issue
Partially solved my issue. DJS allocates 2GB+ on startup. Default max allowed allocation for NodeJS is 2GB (even if the VM has much more). Increasing
--max-old-space-size to 3GB solved my issue temporarily (now I just need to get my caches to not allocate 2GB on startup)
Probably ran into this only now just because my bot has been steadily getting invited to more and more serversYes, nearly same time, I manually run both independently but yes, at same time.
I need ws connection to send messages to discord via worker, update roles once boosts are removed etc. did not wanted to use raw apis
Don't think so, their message still contains "1000" number
I've allocated 12gb memory to bot, it was taking ~9gb and in case of clean process restart, in use memory should reset to 0 and I would get log in
ready event but that's not happening
I just used it as it maintains channels and users cache so while migrating to worker, I don't have to re-write any code and my existing code keeps working as expected.
like
I'll try to remove client login and use core pkg in worker process, then I'll have to make a fetch call to discord every time instead of using djs client cache (which is fine I guess at my scale)
Can you please share some details about identify calls? not able to find any resources online.
Since I only have ready event listener on worker and still used and why would it cause WebSocket is not open: readyState 0 (CONNECTING) error
Oh found this https://discord.com/developers/docs/topics/gateway#identifying
Clients are limited to 1000 IDENTIFY calls to the websocket in a 24-hour period. This limit is global and across all shards, but does not include RESUME calls. Upon hitting this limit, all active sessions for the app will be terminated, the bot token will be reset, and the owner will receive an email notification. It's up to the owner to update their application with the new token.Thanks a lot for your help, really appreciate it. But now I'm wondering how big bots scale with only 1 process actually listening gw events. I'll try to change my implementation If I shard my bot (I use autoShard flag rn) and make it so that 1 process/shard will get events from specific guilds, will
identify calls still be used from multiple processes? how is that handled?
Got it, thanks a lot ā¤ļø
Yes, I'm not planning to go to traditional sharding, shards: "auto" client flag should be good enough for me.
I'm not very familiar with node.js worker threads, for me it's a single threaded process so I just spawned separate pm2 process bb-bot and bb-worker just that I kept file & process name as worker (which is a listener on multiple redis queues)
I like this concept and at scale I can switch to kafka instead of redis queues.
Would love your opinion tho, if I should switch to nodejs worker threads.. reading about those is in my todo xD
@Qjuh "Clients are limited to 1000 IDENTIFY calls to the websocket in a 24-hour period"
Does this mean 1000 per ws connection or per client? :thinKappa:
š«”After your app sends a valid Identify payload, Discord will respond with a Ready event which indicates that your app is in a successfully-connected state with the Gateway. The Ready event is sent as a standard Dispatch (opcode 0).
Ready event is not propogated to me? since I have logs in ready event listener.
Also, if bot is receiving events why would djs send new IDENTIFY call?
I mean this does not sounds like root cause for - WebSocket is not open: readyState 0 (CONNECTING)
Maybe it's handling on disconnect/resume events, Ill try to understand library code and read the docs š«
š