Say goodbye before dropping the socket, and specify that - #2
Merged
Merged
Conversation
Every one of E7's 45 server logs ended the same way:
1 violation(s)
ConnectionClosedError: no close frame received or sent
The C++ client dropped the TCP connection without sending a WebSocket close
frame. It went unnoticed through every previous conformance run because in
all of them the *server* ran out of steps first and closed the connection
itself. E7 is the first experiment where the client finishes first - which
is also what a real env client does when it reaches its episode budget.
Three things were wrong, in three places.
**The client** did not send one. It now sends status 1000, per RFC 6455
section 5.5.1, before closing the socket.
**The specification had a hole.** Section 7 described four ways the server
closes and said nothing at all about the client stopping. New section 7.5:
a client may stop at any time and that is not an error - the server keeps no
state that outlives the connection - but it SHOULD send a close frame, so
that an operator reading the logs does not have to wonder whether a client
crashed.
**The conformance server was stricter than the specification.** It counted
any client disconnect as a violation, including a clean one. That is exactly
the failure its two severity levels exist to prevent, and it took a real
experiment to expose it. A clean close now satisfies 7.5; a missing close
frame is a note, which is the level a SHOULD deserves.
Verified both ways: the new client reports `ok 7.5` and no violations, and
the previous binary, kept for the comparison, reports `note 7.5` and still
no violations. The cross-language CI job passes locally against the modified
client, ldd allowlist included.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
All 45 server logs from E7 ended with
ConnectionClosedError: no close frame received or sent. The C++ client dropped the socket without aWebSocket close frame. It went unnoticed because in every previous
conformance run the server ran out of steps first; E7 is the first
experiment where the client finishes first, which is what a real env client
does when it reaches its episode budget.
Three things were wrong:
RFC 6455 section 5.5.1;
and nothing about the client stopping. New section 7.5;
disconnect as a violation. That is the failure its two severity levels
exist to prevent. A clean close now satisfies 7.5; a missing frame is a
note.
Verified both ways, and the cross-language CI job passes locally against the
modified client.
🤖 Generated with Claude Code