In DiscordWebSocket and DiscordVoiceWebsocket the from_client factory
methods can hang indefintely on all websocket ops. We set static
timeouts and attempt to reconnect if we time out.
Additionally, do not return from DiscordVoiceWebSocket.from_client
until we set up the keep alive thread, which is created after we
receive the READY payload.
In DiscordWebSocket and DiscordVoiceWebsocket the from_client factory
methods can hang indefintely on all websocket ops. We set static
timeouts and attempt to reconnect if we time out.
Additionally, do not return from DiscordVoiceWebSocket.from_client
until we set up the keep alive thread, which is created after we
receive the READY payload.
The library worked with the assumption that whenever the recv call for
the websocket would lead to a closure, the close method would be called
to signal closure and as a result our close method would be called.
This assumption turned out to be false as the websockets library would
instead call an internal function named close_connection instead. So to
solve our problem we need to override this function instead of close.
This should have a more uniform approach to rate limit handling. Instead
of queueing every request, wait until we receive a 429 and then block
the requesting bucket until we're done being rate limited. This should
reduce the number of 429s done by the API significantly (about 66% avg).
This also consistently checks for 502 retries across all requests.
khazhyk
Rapptz
cookie
Jake