Repository navigation
feat: add transport compression - #476
Merged
Merged
Conversation
Signed-off-by: davfsa <davfsa@gmail.com>
davfsa
commented
Sep 21, 2025
davfsa
force-pushed
the
feat/transport-compression
branch
from
September 21, 2025 14:01
40f8e48 to
ab27fe5
Compare
Contributor
|
very nice very nice |
topi314
requested changes
Sep 22, 2025
Member
There was a problem hiding this comment.
generally looks good, just a few things I'd change
topi314
requested changes
Sep 22, 2025
8000
Comment thread
gateway/gateway_transports.go
Resolved
davfsa
marked this pull request as draft
September 22, 2025 21:47
davfsa
marked this pull request as ready for review
September 23, 2025 07:12
Signed-off-by: davfsa <davfsa@gmail.com>
topi314
requested changes
Oct 7, 2025
topi314
approved these changes
Oct 7, 2025
Member
|
thanks! |
sentinelb51
added a commit
to sentinelb51/disgo
that referenced
this pull request
Oct 16, 2026
…nnecting Since the transports were added (disgoorg#476), parseMessage returns every decode error from ReceiveMessage, and listen handles it as a dead connection: "failed to read next message", close with 1012, reconnect and resume. The transport interface says a frame that fails to parse yields a nil Message, and listen has the matching "No message (probably parsing error), just continue" branch, which nothing reaches any more. Before disgoorg#476 such a frame was logged and skipped. Decode errors of the data are ordinary: Discord adds channel, component, interaction and integration types, which discord's unmarshalers reject ("unknown channel with type 17 received"). The sequence of the rejected dispatch was never stored, so the resume replays it, it fails again, and the session loops through reconnects for as long as Discord replays it; a GUILD_CREATE with a new channel type keeps a bot from ever settling. A decode error of the message data is now a messageDataError, and parseMessage skips that frame (logged, nil Message, no error). The frame was read whole before its data was decoded, so the decoder and a zlib or zstd stream are where the next frame starts. Errors reading the frame itself (I/O, decompression, malformed JSON) still close and reconnect, as a stream may be out of step after those. Proof: TestGatewaySkipsUndecodableData (fake gateway sends a CHANNEL_CREATE of type 999, then a TEST_EVENT with seq 3, uncompressed, zlib-stream and zstd-stream) sees the client reconnect for all three before, and seq 3 arrive on the same connection after: go test -race -count 3 -run TestGatewaySkipsUndecodableData ./gateway go test -run Decode ./gateway passes unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VRMfn49UbzGanZA9mpsR8F
This file contains hidden or 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
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.
No description provided.