discord.js: Network Failure Unhandled
Please describe the problem you are having in as much detail as possible:
An unhandled exception, as follows, is thrown when my network adaptor is disabled. This seems odd, as I was under the impression that this should be handled gracefully by the disconnect event.
Error: getaddrinfo ENOENT gateway.discord.gg:443
at Object.exports._errnoException (util.js:1034:11)
at errnoException (dns.js:33:15)
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:73:26)
Include a reproducible code sample here, if possible: The exception is thrown whenever there is any active connection to the Discord API, such as below.
const Discord = require('discord.js');
let robot = new Discord.Client();
let token = 'example123';
robot.login(token);
Further details:
-
discord.js version: 11.1.0.
-
node.js version: 7.8.0.
-
Operating system: Windows 10 Pro 10.0.15063 Build 15063.
-
Priority this issue should have – please be realistic and elaborate if possible: Medium. This exception may not be thrown very often, but if the intention is for
disconnectto handle it, it could cause ungraceful failures in some cases, which would seem undesirable. -
I found this issue while running code on a bot account
- I have also tested the issue on latest master, commit hash:
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 2
- Comments: 20 (15 by maintainers)
I disagree, we aren’t responsible for your internet. If you need to keep something hosted 24/7 buy yourself some hosting or get better internet.
we will not keep a thread open “occasionally polling to see if it can reconnect”. that is objectively stupid. you can poll yourself and call login if you need to.
this is your internet, not a lib problem
Personally, I think that the library should be tolerant of various network faults. If no one else bothers to implement this, I will eventually.
If that’s the behaviour the user wants, I don’t see how that’s ‘objectively stupid’. It’s hardly like that would be an intensive operation, and it could be made optional. But, in any case, this issue started with the even more basic expectation that the
disconnectevent be fired in the case of a network failure instead of an exception being thrown. If this were done, a user could implement their own reconnection attempts. Although, having said this, having reconnection functionality out of the box would clearly be valuable to some users as has been demonstrated by this issue thread.That’s not what the issue is about. It’s about gracefully handling network interruptions, like every other half decent piece of software.
@ChrisTalman How exactly would you handle such an exception? If you can’t get DNS info about an address, then you can’t reconnect. The only thing you can do at this point is to shut down the process.
“You can poll yourself and call login”
That it patently untrue, because the exception is closing the process out leaving no opportunities to do this.
@devsnek Well, in this case, my Internet was fine, and I deliberately disabled my network adaptor to see whether a loss of connection would be handled gracefully. It was not. Strictly speaking, is this not what the
disconnectevent is intended to handle? Its description is as follows: ‘Emitted when the client’s WebSocket disconnects’. Is this not a case of the client’s WebSocket disconnecting?Mostly fixed in master, may still error on failed reconnects (not sure can’t test atm)
I’m not sure. I didn’t see this issue mentioned in the release notes for
11.3.I certainly know that socket hang exceptions still seem to happen (for instance, see #2047). This may or may not be related to the network failure handling, but this is difficult to determine given that in both cases the exception is thrown out of nowhere. Both certainly concern appropriately handling failure on the network, though.