From my understanding, a socket end event is emitted internally after it fails to establish a connection after x attempts (noted from reading debug event).
The issue the library currently faces is that it does not act on this event being fired. If you are proxying your connection and it fails multiple times (such as HTTP 403) then the event will not be handled and any packages using this library will not be notified, leaving the bot in a state of limbo.
I believe there is an issue further down the line; debugging tells us that the socket attempts to reconnect multiple times but does not break out of this loop - meaning there is no maximum connection attempt amount.
Simple proposal would be to limit socket connection events to 7 or so by default (1, 2, 4, 8, 16, 32, 64 second delays between) and emit a timeout event if the connection is never established. Once a connection is established this ticker can of course be reset.
From my understanding, a socket
endevent is emitted internally after it fails to establish a connection after x attempts (noted from readingdebugevent).The issue the library currently faces is that it does not act on this event being fired. If you are proxying your connection and it fails multiple times (such as HTTP
403) then the event will not be handled and any packages using this library will not be notified, leaving the bot in a state of limbo.You can refer to the line I'm talking about here.
I believe there is an issue further down the line; debugging tells us that the socket attempts to reconnect multiple times but does not break out of this loop - meaning there is no maximum connection attempt amount.
Simple proposal would be to limit socket connection events to 7 or so by default (1, 2, 4, 8, 16, 32, 64 second delays between) and emit a timeout event if the connection is never established. Once a connection is established this ticker can of course be reset.
Cheers.