fix(test): block accepted sockets so Windows test servers stop flaking

[zackees]

Symptom

Check (windows-latest) failed on #1385, in a test that PR does not touch:

usb::data::tests::populate_online_cache_falls_back_to_json_when_proto_is_missing ... FAILED
thread '<unnamed>' panicked at crates\fbuild-core\src\usb\data.rs:643:55:
called `Result::unwrap()` on an `Err` value: Os { code: 10035, kind: WouldBlock,
  message: "A non-blocking socket operation could not be completed immediately." }

(The second panic, Any { .. } at data.rs:680, is just handle.join().unwrap()
resurfacing the server thread's failure.)

Cause

Both test servers set their listener non-blocking and correctly handle
WouldBlock around accept(). What neither handled:

On Windows, an accepted socket inherits the listening socket's
non-blocking mode. On Unix, accept() returns a blocking socket regardless.

So stream.read(&mut buf).unwrap() on the fresh connection returns
WSAEWOULDBLOCK whenever the client's bytes have not arrived in the microsecond
between accept and read. Nothing about the failure points at socket
mode — it lands in a test about USB VID overlay fallback, on Windows only,
intermittently.

os error 10035 is WSAEWOULDBLOCK, which is why kind is WouldBlock rather
than something that reads as a connection problem.

Fix

Put the accepted socket back into blocking mode, which is what the surrounding
read/write sequence already assumes.

This is not a new pattern — crates/fbuild-cli/tests/test_emu_exit_code.rs's
mock daemon has done exactly this since it was written:

stream.set_nonblocking(false).expect("blocking per-connection");

The two servers fixed here just never got the same treatment.

Scope

• crates/fbuild-core/src/usb/data.rs — the one that failed
• crates/fbuild-cli/src/cli/port_scan.rs — same shape, same latent flake

crates/fbuild-core/src/usb/profiles.rs has an identically-configured listener
but only counts accepts (Ok(_) => extra_requests += 1) and never reads from
the stream, so it cannot hit this. Left alone rather than changed for symmetry.

Verified: usb::data 8 passed, port_scan 25 passed, clippy -D warnings
clean. A timing flake can't be proven fixed by one green run — the argument is
the mechanism, and it's the same one the working mock daemon already relies on.

[coderabbitai]

Warning

Review limit reached

Next included review available in 54 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 415376e6-b9d4-4276-ae83-0c23dc50a68e

📥 Commits

Reviewing files that changed from the base of the PR and between 9f82da3 and b8c2b59.

📒 Files selected for processing (2)

• crates/fbuild-cli/src/cli/port_scan.rs
• crates/fbuild-core/src/usb/data.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}