test(windows-smoke): check the local server by connecting when sockets can't be listed #52

Merged
jared merged 1 commits from fix/smoke-listen-check into main 2026-11-09 23:10:17 -05:00
Owner

The Windows smoke test failed on every run, main included (run 3145), always on the same check, "local server listening". The other checks all pass or are n/a.

Cause

The runner session can't enumerate sockets. Get-NetTCPConnection returns "No matching MSFT_NetTCPConnection objects", and the workflow's own netstat dump is empty, even for port 9222, the WebView2 DevTools port the script is connected to the whole time. In the same runs, the app loads from http://localhost:44548 and an HTTP probe returns 200. The server is fine; the socket listing isn't.

Fix

When the socket list comes back empty, the script tests what the check exists for (cinny #43: the server is bound to 127.0.0.1 only) by connecting:

  • 127.0.0.1:44548 must accept the connection;
  • every non-loopback IPv4 address of the machine must refuse it on port 44548.

The detail line says which path ran, for example socket list unavailable; 127.0.0.1: open; LAN 10.x.x.x: not reachable. Where the socket list works, the original check runs unchanged.

Verified

  • node --check passes.
  • I ran the probe locally against a throwaway server. Bound to 127.0.0.1: loopback open, LAN refused, so the check passes. Bound to 0.0.0.0: LAN open, so the check fails, which is the exposure #43 guards against.
  • I'm starting a smoke run from this branch now and will report the result on this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA

The Windows smoke test failed on **every** run, `main` included (run 3145), always on the same check, "local server listening". The other checks all pass or are n/a. ## Cause The runner session can't enumerate sockets. `Get-NetTCPConnection` returns "No matching MSFT_NetTCPConnection objects", and the workflow's own `netstat` dump is empty, even for port 9222, the WebView2 DevTools port the script is connected to the whole time. In the same runs, the app loads from `http://localhost:44548` and an HTTP probe returns 200. The server is fine; the socket listing isn't. ## Fix When the socket list comes back empty, the script tests what the check exists for (cinny #43: the server is bound to 127.0.0.1 only) by connecting: - `127.0.0.1:44548` must accept the connection; - every non-loopback IPv4 address of the machine must refuse it on port 44548. The detail line says which path ran, for example `socket list unavailable; 127.0.0.1: open; LAN 10.x.x.x: not reachable`. Where the socket list works, the original check runs unchanged. ## Verified - `node --check` passes. - I ran the probe locally against a throwaway server. Bound to `127.0.0.1`: loopback `open`, LAN `refused`, so the check passes. Bound to `0.0.0.0`: LAN `open`, so the check fails, which is the exposure #43 guards against. - I'm starting a smoke run from this branch now and will report the result on this PR. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
jared added 1 commit 2026-11-09 21:45:00 -05:00
The `windows` runner session can't enumerate sockets: Get-NetTCPConnection
and netstat come back empty even for the DevTools port the script is
connected to, so "local server listening" failed on every run (main
too, run 3145) and masked real regressions.

When the socket list is empty, test what cinny #43 is about directly:
the server must accept a connection on 127.0.0.1:44548 and refuse it on
every non-loopback IPv4 address of the machine. The list-based check is
kept for runners where it works.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
jared merged commit 9ecfb59683 into main 2026-11-09 23:10:17 -05:00
Sign in to join this conversation.