Discord.js: arbitrary SHARDING_READY_TIMEOUT throwing errors on long load up

Created on 18 Jan 2019  Â·  5Comments  Â·  Source: discordjs/discord.js

Please describe the problem you are having in as much detail as possible:
From Commit: https://github.com/discordjs/discord.js/pull/2902/commits/bd277a8daeb8659d8e165af5d9f011ae3345c17b#diff-c43f66e4132e3d2e312ea324400cb38bR201
Now in:
https://github.com/discordjs/discord.js/blob/master/src/client/Client.js#L262

Error thrown when a shard takes longer than 25 seconds to start up, regardless of when (or if) it attempts to log in. The logic provided for the time was that it _shouldn't_ take longer than 25 seconds to log into Discord, which is more than reasonable from the time of the .login(), but is problematic when a an application has other lengthy tasks to complete before logging in.

As a side, this is breaking when a user is also met with either of these issues (the latter being my case until I remove the timeout code):
https://github.com/discordjs/discord.js/issues/2955
https://github.com/discordjs/discord.js/issues/2323
Include a reproducible code sample here, if possible:

//shard.js
const { ShardingManager } = require("discord.js");
const manager = new ShardingManager(`./index.js`, { totalShards: 1 });
manager.spawn();
//index.js
setTimeout(() => {}, 30e3);

Further details:

  • discord.js version: Master: 8230255c68b94d68a4e8ffc559a98d08d1a08a7c
  • Node.js version: v8.11.3
  • Operating system: Windows 7 Pro
  • Priority this issue should have – please be realistic and elaborate if possible: Low, Although Medium if more people encounter the other two aforementioned issues since the two combined can break programs. I understand that people won't often into this problem and think the fix is easy: Either remove the limitation, find out a limit that actually means something in terms of the proper functioning of the connection between the bot and Discord, or allow the user to define that variable in the Sharding Manager if they want to-- a variable named after the error in question.
  • [x] I have also tested the issue on latest master, commit hash: 8230255c68b94d68a4e8ffc559a98d08d1a08a7c
medium gateway bug

Most helpful comment

@vladfrangu Thanks for replying. I have updated to the latest commit as of today and I am pleased to announce that the shards don't even take longer than a few seconds to start up anymore so as far as I'm concerned the issue is fixed. :+1:

Edit: I pinged the wrong person lol.

All 5 comments

I'm starting to suspect it's the underlying UWS library's problem

My error log: https://pastebin.com/cwjnFYNb
My debug log: https://pastebin.com/BNcEYag3

DJS Hash: https://github.com/discordjs/discord.js/commit/32a432f4a55094ea7c0f6260529f8f911ea8a2de

@vladfrangu

@shourinkai can you please try the latest commit of discord.js, bb92289e45b4d9d576a4277d0bfa082814d2bc20? It has the latest iteration of bug-fixes (and hopefully no more issues) that revolve around internal sharding, and who knows, maybe that'll fix your issues!

@rumblefrog your issues seem unrelated to this specific issue, which refers to a ShardingManager hand-made timeout, something I have not touched in my PRs.

From your logs however, you seem to get a few

2019-04-04T05:37:16.621Z - error: Unhandled exception: TypeError: Cannot read property 'get' of undefined
    at MessageReactionAdd.getMessage (/estat/Reaction_Role/node_modules/discord.js/src/client/actions/Action.js:44:24)
    at MessageReactionAdd.handle (/estat/Reaction_Role/node_modules/discord.js/src/client/actions/MessageReactionAdd.js:25:26)
    at Object.module.exports [as MESSAGE_REACTION_ADD] (/estat/Reaction_Role/node_modules/discord.js/src/client/websocket/handlers/MESSAGE_REACTION_ADD.js:4:37)
    at WebSocketManager.handlePacket (/estat/Reaction_Role/node_modules/discord.js/src/client/websocket/WebSocketManager.js:390:31)
    at WebSocketShard.onPacket (/estat/Reaction_Role/node_modules/discord.js/src/client/websocket/WebSocketShard.js:398:22)
    at WebSocketShard.onMessage (/estat/Reaction_Role/node_modules/discord.js/src/client/websocket/WebSocketShard.js:264:10)
    at WebSocket.onMessage (/estat/Reaction_Role/node_modules/ws/lib/event-target.js:120:16)
    at WebSocket.emit (events.js:193:13)
    at Receiver.receiverOnMessage (/estat/Reaction_Role/node_modules/ws/lib/websocket.js:789:20)
    // WS Stuffs
    at writeOrBuffer (_stream_writable.js:399:5). Exiting.

Which are likely caused by news channels. I recommend updating discord.js to at least bb92289e45b4d9d576a4277d0bfa082814d2bc20, since, as of that commit, unknown channels should not default, and thus shouldn't cause any more issues

@vladfrangu Thanks, I have updated to the latest, should I make a new issue regarding it or does an issue on this specific problem already exist? (I can't find another related one)

@rumblefrog There has been a PR already merged to prevent the defaulting to GuildChannel, and there's a PR pending for said channels ( #3168 ). So, I don't think an issue is needed. Unless it's not fixed by either the latest commit or the before-mentioned PR. 😄

@vladfrangu Thanks for replying. I have updated to the latest commit as of today and I am pleased to announce that the shards don't even take longer than a few seconds to start up anymore so as far as I'm concerned the issue is fixed. :+1:

Edit: I pinged the wrong person lol.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

PassTheMayo picture PassTheMayo  Â·  3Comments

Lombra picture Lombra  Â·  3Comments

Blumlaut picture Blumlaut  Â·  3Comments

xCuzImPro picture xCuzImPro  Â·  3Comments

ghost picture ghost  Â·  3Comments