Repository navigation
fix(realtime): stop reporting the gateway's own 1002 as the upstream's close code - #1339
Merged
Merged
Conversation
…s close code tungstenite replaces an upstream Close whose code may not be sent (1004, 2999, ...) with its own 1002 "Protocol violation" and drops the original code, so the relay forwarded 1002 to the client and its error event said the upstream had closed with 1002. Treat exactly that frame as the library's replacement: the client gets 1011 and the event says the upstream sent a close frame the gateway cannot relay (an invalid close code, or 1002 "Protocol violation"). Any other legal code, 1002 with a different reason included, is still relayed as received. The sibling ends no longer claim codes the upstream never sent: a Close without a status code, a transport or protocol error, and a stream that ends without a Close each get an event describing what happened. The client's close code (1011), its reason and the access-log status are unchanged.
|
Warning Review limit reached
This review includes 2 billable files and costs up to $0.50.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 38 minutes for your next included review. View limit details
Comment |
…t for event and log A unit test drives tungstenite with a Close(1004) and asserts it yields exactly LIBRARY_REJECTED_CLOSE, so a library bump that changes the substitute fails here instead of silently reporting 1002 again. The upstream-error event now carries the same cause chain as the access log, and the drop e2e pins the transport-error path it actually takes.
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
1 participant
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.
When an upstream closes
/v1/realtimewith a code that may not be sent in a Close frame (1004, 2999, ...), the client got Close 1002 "Protocol violation" and an error event sayingupstream websocket closed with code 1002: Protocol violation. The upstream never sent 1002: tungstenite replaces any received Close whose code is not allowed with its own(1002, "Protocol violation")frame and drops the original code, and the relay forwarded that as if it were the upstream's.The library gives no way to recover the original code, and a genuine upstream
(1002, "Protocol violation")looks identical. So that exact frame is now treated as the library's replacement: the client gets 1011, and theserver_errorevent says the upstream sent a close frame the gateway cannot relay — an invalid close code, or 1002 "Protocol violation". Any other legal code, including 1002 with a different reason, is still relayed as received.The other upstream ends in the same relay also claimed codes the upstream never sent, and are fixed here too:
closed with code 1005; it now says the upstream closed without a status code;closed with code 1006: upstream error; it now saysupstream websocket connection failed: <error>, with the same cause chain the access log records;closed with code 1006; it now says the connection ended without a close frame.The client's close code (1011), the Close reason and the access-log status are unchanged for all three.
Tests:
realtime-close-e2egets a raw-frame mode in its mock upstream to send whatwsrefuses to (Close 1004 / 2999 and an oversized Close), plus assertions on the exact event message for the no-status, drop and protocol-error ends and a check that 1002 with its own reason is still relayed. Five of the cases fail on main and pass with this change. A unit test also drives tungstenite with a Close(1004) and asserts it yields exactly the frame the relay matches, so a library bump that changes the substitute fails in CI rather than silently reporting 1002 again.🤖 Generated with Claude Code