fix(WebSocketShard): wsCloseTimeout in wrong if #8981
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
github-actions
bot
requested review from
iCrawl,
kyranet,
SpaceEEC and
vladfrangu
| this.closeEmitted = false; | ||
| this.debug( | ||
| `[WebSocket] Adding a WebSocket close timeout to ensure a correct WS reconnect. | ||
| Timeout: ${this.manager.client.options.closeTimeout}ms`, | ||
| ); | ||
| this.setWsCloseTimeout(this.manager.client.options.closeTimeout); |
There was a problem hiding this comment.
These changes are very similar to the
file: https://github.com/legendhimself/discord.js/blob/01797d3b0cd316a97853f34a971034c1904b4efb/packages/discord.js/src/client/websocket/WebSocketShard.js#L824
pr: #7626
this.connection.close(closeCode);Once this ^ is invoked the connection is either CLOSING or CLOSED state.
There was a problem hiding this comment.
It's only CLOSING state, never CLOSED (because it was OPEN before the .close() call), so yes it is similar, but not exactly the same. Especially because there are other reasons why the Websocket could be CLOSED that shouldn't need a wsCloseTimeout because they already closed the Websocket.
There was a problem hiding this comment.
CLOSED check was added for very large scaled bots (Just to cover every case). And after close() is invoked the ws waits for the close frame and then marks the connection CLOSED. Receiving that close frame differs (might be instant and can happen when the execution is in the current scope) hence that's why I had the check.
There was a problem hiding this comment.
Websocket doesn’t wait for the close frame though… it’s an async callback. So that‘ll never happen while in this scope, status will always be CLOSING here…
|
It can be closed, it's superseded by #8989 |
Please describe the changes this PR makes and why it should be merged:
Fixes issues introduced by #8956 because it added the
wsCloseTimeouteven when the Websocket was alreadyClosedbefore. This lead to the timeout trying to close the new connection after it successfully reconnected.Also added a clearing of the
wsCloseTimeoutbefore making a new connection to prevent any other obscure occurences like this.Status and versioning classification: