[quality] unit meow.test.ts leaks real TLS connections to api.thecatapi.com under msw 3 — flaky build-test (ERR_TLS_CERT_ALTNAME_INVALID unhandled error) #284

Finding

__tests__/issueCommentTest/meow.test.ts is meant to run offline (server.listen(failOnUnhandledRequest)), but under msw 3.0.1 it opens real TLS connections to api.thecatapi.com:443 from every test that exercises the retry path (second fetch after a cancelled body or a network error):

• retries a transient status and then succeeds
• degrades to a note when the cat api keeps failing
• degrades to a note on a network error
• retries a network error up to the attempt limit
• still retries when cancelling the response body fails

Mechanism (verified by wrapping tls.connect in a vitest setup file and logging the stack): after src/issueComment/meow.ts cancels the 503/erroring response body, undici closes the mock socket and reconnects (onHttpSocketClose → resume → connect). On the new connection undici attaches its data reader before it writes the request. @mswjs/interceptors treats a connection that reads before any bytes arrive as "non-HTTP" and, one setImmediate later, calls TlsSocketController.passthrough() → createRealSocket() → tls.connect({ host: 'api.thecatapi.com', port: 443, servername: 'api.thecatapi.com' }) (node_modules/@mswjs/interceptors/lib/node/source-*.js, the onClientRead block; net-*.js passthrough()). The mocked response is still delivered, so all 39 tests pass — the real socket is a stray.

The stray socket is what turns build-test red: when its handshake fails, undici's onHttpSocketError hits assert(err.code !== "ERR_TLS_CERT_ALTNAME_INVALID") and vitest reports an Unhandled Error after all tests have passed:

Vitest caught 1 unhandled error during the test run.
AssertionError: The expression evaluated to a falsy value:
  assert(err.code !== "ERR_TLS_CERT_ALTNAME_INVALID")
 ❯ TLSSocket.onHttpSocketError node:internal/deps/undici/undici:7806:7
 ❯ node_modules/@mswjs/interceptors/lib/node/source-D5U7_Vkx.js:2121:30
This error originated in "__tests__/issueCommentTest/meow.test.ts" test file.
 Test Files  80 passed (80)   Tests  1608 passed (1608)   Errors  1 error

Whether the error lands before the worker exits is a race, so the check is flaky, not consistently red: run 37149344123 (PR #244, head 98a1a04, no changes to this file or to src/) failed exactly this way while sibling runs 37149297190, 37149429039, 37150221504 and 37150356697 minutes apart passed. Locally the unhandled error reproduces 3/3 on main@3fc21f2 with npx vitest run __tests__/issueCommentTest/meow.test.ts (Node 26.10.0, msw 3.0.1). It also means the unit suite is not actually hermetic: it depends on outbound network to the real cat API.

Recommendation

• Stop the unit /meow suite from reaching the real network under msw 3. Candidates, in order of preference: (a) report/track the reader-before-write passthrough in mswjs/interceptors and pin to a release that fixes it; (b) make the retry-path tests not need a reconnect (e.g. hand the first attempt a body-less HttpResponse the client does not have to cancel), keeping the retry assertions; (c) as a last resort, point catApi at an in-process loopback server for the retry tests so a passthrough cannot leave the host.
• Add a regression guard: fail the suite if tls.connect/net.connect is called with a non-loopback host from a unit test (wrapping before server.listen is not enough — msw builds its mock sockets through the same tls.connect, so the guard has to distinguish the interceptor's createRealSocket path; a simple host-based wrapper breaks 15 tests, verified).

Until then, a build-test red whose only failure is this unhandled error on an untouched meow.test.ts should be read as this flake, not as the PR's fault.

Priority

• Impact: high (flaky required check; unit suite silently depends on egress)
• Effort: medium

Filed by quality agent (hold-gated mode)

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: 22cb375

— hive: agent=quality backend=copilot model=claude-fable-5.1 copilot=1.0.88