From dcf6d0c13531a972c686c6df77bb1599aa69a5ba Mon Sep 17 00:00:00 2001 From: ozpool <151670776+ozpool@users.noreply.github.com> Date: Thu, 4 Jun 2026 22:27:11 +0530 Subject: [PATCH] rpc: accept Windows reset error in websocket read limit test (#34928) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ### Summary `TestServerWebsocketReadLimit/limit_with_large_request_-_should_fail` is flaky on `windows/amd64` (see [run 25364841576](https://github.com/ethereum/go-ethereum/actions/runs/25364841576/job/74378334589) referenced in #34877): ``` --- FAIL: TestServerWebsocketReadLimit/limit_with_large_request_-_should_fail (0.02s) server_test.go:279: unexpected error for read limit violation: read tcp 127.0.0.1:56703->127.0.0.1:56700: wsarecv: An existing connection was forcibly closed by the remote host. ``` When the server enforces the read limit and tears the connection down, the client's read can race the close frame. On Windows the OS surfaces that race as `wsarecv: An existing connection was forcibly closed by the remote host` instead of the gorilla `CloseError(1009)`, `websocket.ErrReadLimit`, or the POSIX `connection reset by peer` the test already tolerates. This change adds `"forcibly closed"` to the set of acceptable error substrings for the failure case, so the Windows reset is recognized as a valid signal that the server enforced the limit. ### Fixes #34877 ### Test plan - [x] `go test -count=5 -run TestServerWebsocketReadLimit ./rpc/` (darwin/arm64) — pass - [x] `go test ./rpc/...` — pass - [x] `go vet ./rpc/...` / `gofmt -l rpc/server_test.go` — clean - [ ] CI on `windows/amd64` confirms the flake no longer trips --------- Co-authored-by: lightclient --- rpc/server_test.go | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/rpc/server_test.go b/rpc/server_test.go index a2b8af2b7f..13e723cad0 100644 --- a/rpc/server_test.go +++ b/rpc/server_test.go @@ -307,7 +307,7 @@ func TestServerWebsocketReadLimit(t *testing.T) { t.Fatalf("expected error for request size %d with limit %d, but got none", tc.testSize, tc.readLimit) } // Be tolerant about the exact error surfaced by gorilla/websocket. - // Prefer a CloseError with code 1009, but accept ErrReadLimit or an error string containing 1009/message too big. + // The error text can vary across platforms when the close races the read. var cerr *websocket.CloseError if errors.As(err, &cerr) { if cerr.Code != websocket.CloseMessageTooBig { @@ -316,7 +316,8 @@ func TestServerWebsocketReadLimit(t *testing.T) { } else if !errors.Is(err, websocket.ErrReadLimit) && !strings.Contains(strings.ToLower(err.Error()), "1009") && !strings.Contains(strings.ToLower(err.Error()), "message too big") && - !strings.Contains(strings.ToLower(err.Error()), "connection reset by peer") { + !strings.Contains(strings.ToLower(err.Error()), "connection reset by peer") && + !strings.Contains(strings.ToLower(err.Error()), "forcibly closed") { // Not the error we expect from exceeding the message size limit. t.Fatalf("unexpected error for read limit violation: %v", err) }