CI caught it: the fake WS test server's close() called conn.close() while its own background _read_loop thread could still be blocked in conn.recv() on that same fd. Closing a socket concurrently with a blocking read on it from another thread isn't reliably immediate across platforms, so the client's close-detection sometimes never saw the FIN in time and the test hung until its 5s timeout. shutdown(SHUT_RDWR) before close() is the standard fix — it's built to safely unblock a concurrent blocking read and deliver the peer a clean FIN right away. 8/8 repeated local runs clean after the fix.