Skip to content

Fix websocket cookbook examples busy-looping after client disconnect - #443

Open
wakqasahmed wants to merge 1 commit into
labstack:masterfrom
wakqasahmed:fix/cookbook-websocket-busy-loop
Open

wakqasahmed wants to merge 1 commit into
labstack:masterfrom
wakqasahmed:fix/cookbook-websocket-busy-loop

Conversation

@wakqasahmed

Copy link
Copy Markdown
Contributor

Both websocket cookbook examples (`cookbook/websocket/gorilla` and `cookbook/websocket/net`) run their write/read loop unconditionally — on a write or read error they log it and loop right back around instead of exiting. Once a client disconnects, every subsequent `WriteMessage`/`ReadMessage` call errors immediately, so the handler spins as fast as possible logging errors forever instead of returning.

Added an early return on both the write-error and read-error paths in each example, so the handler exits (and `defer ws.Close()` runs) as soon as the connection is gone, matching how these examples are meant to demonstrate correct websocket handling.

Added a test per example that connects a client, closes it immediately, and asserts the handler goroutine actually returns within a couple seconds — this fails against the old code (the handler never returns, so the test would time out) and passes with the fix.

@wakqasahmed
wakqasahmed force-pushed the fix/cookbook-websocket-busy-loop branch from 34ffaec to 6ca5971 Compare September 13, 2026 07:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant