fix(runtime): HTTPServerAgent.test.ts beforeAll times out under the test runner

Parent: #66 · Blocks #760

A debugger session cannot attach to Home over a unix-socket inspector URL, so every inspector test that drives a spawned process fails.

Repro (Darwin arm64, JSC debug build):

home-debug --hot --inspect-wait=unix:insp.sock server.ts

Home prints the banner and Listening on unix:insp.sock, but no socket is connectable at that path and the process's own log shows [socket] onConnectError (2) — ENOENT — followed by [debugger] waited: forever. Pinned Bun 4982b91e37 run the same way accepts the connection.

Effect: the unchanged test/cli/inspect/HTTPServerAgent.test.ts times out at 5,001 ms waiting for HTTPServer.listen / HTTPServer.serverRoutesUpdated, even with the agent notifications restored in 2d7833e. Pinned Bun passes it.

Worth checking first: whether unix:<relative-path> is resolved against a different working directory than the spawning test's cwd, and whether Home's debugger takes a connect path where upstream listens (BUN_INSPECT_CONNECT_TO vs BUN_INSPECT) — packages/runtime/src/jsc/VirtualMachine.zig configureDebugger and the internal:debugger builtin that prints the banner.

The reported Unix-socket attach failure no longer reproduces on current origin/main at c6ab9aeeb.

A clean required ReleaseFast build (explicit pinned Bun object graph and WebKit libraries) attached over the unchanged relative unix:inspector-….sock path, delivered Inspector.initialized, HTTPServer.listen, both initial and hot-reloaded HTTPServer.serverRoutesUpdated events, and HTTPServer.close. The unchanged HTTPServerAgent.test.ts passes 1/1, and the complete unchanged inspector directory passes 35 tests / 0 failures / 122 assertions with four pre-existing upstream TODOs.

There was no transport-specific source delta in this checkpoint; the earlier ENOENT result was from an older/stale native artifact and is not present after a clean build of current main. Closing based on the exact current reproduction and suite evidence.

Correcting the root cause in the description above — it was wrong.

The evidence I filed (Listening on unix:… followed by [socket] onConnectError (2)) came from a probe that had nothing listening on the other end, so ENOENT was the correct result, and the banner misled me: internal:debugger prints "Listening on <url>" in the connect path too, whenever debug.url is undefined (src/js/internal/debugger.ts). A bare unix:<path> URL makes Bun connect to a socket the debugger client is listening on — which is what the test's connect() helper in junit-reporter.ts does: it calls listen().

Re-measured on the same build, Home matches pinned Bun everywhere I can isolate:

So there is no unix-socket transport gap, and this issue as written should not be worked on. What remains true is only the observable in #760: test/cli/inspect/HTTPServerAgent.test.ts times out in its beforeAll under Home while pinned Bun passes it, and no inspector-*.sock shows up. Since a verbatim replication of that hook connects, the cause is something else in the test-runner path (the child is spawned with stdout/stderr: "inherit" there, which my replication did not use).

Renaming/repurposing this issue to the actual observable rather than leaving a wrong diagnosis in the tracker; the next step is to bisect the remaining differences between the replication and the test (stdio mode first).

Resolved on origin/main by c6ab9aeeb. On a fresh JSC debug build of that tree the unchanged test/cli/inspect directory is 8 pass / 2 todo / 1 fail, exactly matching pinned Bun 4982b91e37; the single failure is inspect.test.ts failing to load because strip-ansi is absent from ~/Code/bun/node_modules, which pinned Bun reproduces.

That includes HTTPServer inspector protocol > should receive serverRoutesUpdated event with route information, the timeout this issue was opened for, and the duplicate clientNavigated case noted on #760.

Leaving the close to @chrisbbreuer. Note the correction above: there was never a unix-socket transport gap — that diagnosis of mine was wrong, and the measurements behind the correction are in the previous comment.