Gateway cleanup #3099
Merged
Gateway cleanup #3099
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also, a close code of 1000 will now warn as unknown.
Always check for a session id before resuming, and fall back to a reidentify if the resume fails. In all cases, wait 1 second after resuming fails in order to not spam log messages.
arqunis
added
the
breaking change
arqunis
approved these changes
Jan 27, 2025
mkrasnitski
added a commit
to mkrasnitski/serenity
that referenced
this pull request
Feb 1, 2025
This commit refactors how the gateway connection being closed gets handled,
and also reworks how resuming is performed. If a resume fails, or if the
session id is invalid/doesn't exist, the shard will fall back to restart
+ reidentify after a 1 second delay. This behavior was only present in
some circumstances before.
Also, cleaned up the loop in `ShardRunner::run` by adding a
`ShardAction::Dispatch` variant, since event dispatch was already
mutually exclusive to hearbeating, identifying, and restarting. The
overall effect is less interleaving of control flow.
Plus, removed the `Shard::{reconnect, reset}` functions as they were
unused.
A notable change is that 4006 is no longer considered a valid close code
as it is undocumented, and neither is 1000, which tungstenite assigns as
`Normal` or "clean". We should stick to the [table of close
codes](https://discord.com/developers/docs/topics/opcodes-and-status-codes#gateway-gateway-close-event-codes)
provided by Discord.
jamesbt365
added a commit
to jamesbt365/serenity
that referenced
this pull request
Feb 2, 2025
This reverts commit 872e19c.
arqunis
pushed a commit
that referenced
this pull request
Feb 3, 2025
A regression introduced by #3099 was that successful resumes will break out of the loop inside `ShardRunner::run`, but they shouldn't (or rather, didn't before). Therefore, only break out of the loop if the resume failed and we had to fallback to reidentifying.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR refactors how the gateway connection being closed gets handled, and also reworks how resuming is performed. If a resume fails, or if the session id is invalid/doesn't exist, the shard will fall back to restart + reidentify after a 1 second delay. This behavior was only present in some circumstances before.
Also, cleaned up the loop in
ShardRunner::runby adding aShardAction::Dispatchvariant, since event dispatch was already mutually exclusive to hearbeating, identifying, and restarting. The overall effect is less interleaving of control flow.Plus, removed the
Shard::{reconnect, reset}functions as they were unused.A notable change is that 4006 is no longer considered a valid close code as it is undocumented, and neither is 1000, which tungstenite assigns as
Normalor "clean". We should stick to the table of close codes provided by Discord.