wai dev's test: the stand-in room service listens without a reverse lookup #663
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/fake-stack-reverse-lookup"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Replaces #661, whose commit message and first body stated things I have since measured to be wrong.
tests/cli_studio.rsfailed on every run on one macOS runner and passed on every other, with "the room service's clock on the relay: not within 30 s". Across 22 runs of that job on 5 November it was 3 of 3 on that runner and 19 of 19 passing elsewhere.Cause. The stand-in room service starts an
HTTPServer, whoseserver_bindcallssocket.getfqdnbefore the server listens. On that host, under the runner's Python 3.15.2,getfqdn("127.0.0.1")takes 35 s, past the 30 swai devwaits. The stand-in relay opens a plain socket, so it was up in about 0.1 s and only the room service stalled. A second macOS host shows the same 35 s; two others answer the same call in milliseconds on the same Python version. Why those hosts are slow is not established, and this change doesn't depend on it.Nothing in the fixture reads the name, so it no longer asks for it.
Tested, on that host and Python, with a stack dump armed:
socket.getfqdn, fromhttp/server.py'sserver_bindOn another host, a
socket.getfqdnplanted to stall for 40 s fails the test with the same message at 30.18 s, and passes with this change in 0.30 s.CI checks out each PR's own head, so a PR already open keeps the old fixture until it carries this commit. The same commit is on #640, #656 and #658.
Changes the test fixture only, so there is no changelog entry.
🤖 Generated with Claude Code
tests/cli_studio.rs failed on every run on one macOS runner and passed on every other runner, 3 of 3 against 19 of 19 on 5 November, with "the room service's clock on the relay: not within 30 s". The stand-in room service starts an HTTPServer, whose server_bind calls socket.getfqdn before the server listens. On that host, under the runner's Python 3.15.2, getfqdn("127.0.0.1") takes 35 s, past the 30 s wai dev waits, and a stack dump of the stalled stand-in shows it there. The stand-in relay opens a plain socket and answers in 0.1 s. Nothing here reads the name, so the fixture no longer asks for it. On that host and Python the room stand-in took 35.5 s and now takes 0.12 s. A socket.getfqdn planted to stall for 40 s fails the test without this change, with the same message, and passes with it. Changelog: none Co-Authored-By: Claude Opus 5.5 <[email protected]>