From bb76b4e44437cbc783150be3baa8cf06534f156f Mon Sep 17 00:00:00 2001 From: Eugene Volen Date: Mon, 10 Aug 2026 14:42:48 +0000 Subject: [PATCH] test(providers): stop the loopback stub inheriting non-blocking mode The models-only test server binds a non-blocking listener so its accept loop can poll for the stop signal between connections. On Windows the accepted socket inherits that mode, so the first read of the request returns WSAEWOULDBLOCK (os error 10035) rather than waiting, the server thread dies, and whichever provider test owned it fails. It fails intermittently rather than always because it depends on whether the request has already landed in the socket buffer by the time the read runs, which is why this surfaces as an unrelated-looking flake on windows-build-and-test. Put each accepted connection back into blocking mode; the two-second read timeout is what bounds the read. Same fix as the e2e loopback server got in #174, applied to the stub this crate owns. Signed-off-by: Eugene Volen --- apps/rocm/src/providers.rs | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/apps/rocm/src/providers.rs b/apps/rocm/src/providers.rs index 7a564f321..c8a3c3083 100644 --- a/apps/rocm/src/providers.rs +++ b/apps/rocm/src/providers.rs @@ -2867,6 +2867,13 @@ mod tests { } match listener.accept() { Ok((mut stream, _)) => { + // The listener is non-blocking so the accept loop can + // poll for the stop signal, but on Windows the accepted + // socket inherits that mode and the read below then + // fails with WSAEWOULDBLOCK instead of waiting for the + // request. Put the connection back into blocking mode; + // the read timeout is what bounds it. + stream.set_nonblocking(false)?; stream.set_read_timeout(Some(Duration::from_secs(2))).ok(); let request = read_http_request(&mut stream)?; if request.starts_with("GET /v1/models ") {