Repository navigation
test: answer a stray GET in the register-hook stand-in servers - #224
Merged
Merged
Conversation
"two concurrent first edits of one session register once" failed about 3 of 10 isolated runs on this host with "Unexpected end of JSON input". Another process here (user agent node, with b3 and traceparent headers) sends GET / to new loopback listeners, and the stand-in servers parsed every request as JSON, so the throw failed whichever test owned the server. They now answer anything but a POST with 404. A new test sends the GET directly, and fails without the guard. The race test passed 30 of 30 isolated runs with it.
bompus
added
the
author:anthropic
Owner
Author
|
@coderabbitai full review |
![bompus-ai-review[bot]](https://avatars.githubusercontent.com/u/253635?s=60&v=4){kind=small}
bompus
added a commit
that referenced
this pull request
Oct 30, 2026
…body (#225) #224 fixed this for the register-hook stand-ins. The same parse-first pattern was in mcp-relay, wake-auto-t3 (7 servers) and mail tests, and one more wake-auto-t3 proxy asserted the path before reading the request: T3 Code's server (t3 serve) sends GET / to new loopback listeners, that GET throws in the handler, and whichever test owns the server fails. strayRequest now lives in test/fixtures and each server calls it first. test/stray-request.test.ts scans the test files and fails for a handler that calls json() without answering a stray request first; it listed these 9 handlers before the change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The test "two concurrent first edits of one session register once" in
test/register-hook.test.tsfailed 3 of 10 isolated runs on this host withSyntaxError: Unexpected end of JSON inputand Bun'sGET - / failed. It passes 30 of 30 with this change, and the whole file passed 3 of 3 runs (37 pass, 0 fail).Cause. The failure is not a race between the two registering processes. Another process on this host sends
GET /to new loopback listeners (user agentnode, withb3andtraceparentheaders; I captured four such requests in 12 runs). The file's stand-in mail servers parsed every request as JSON, so that bodiless GET threw insidefetch, and Bun failed whichever test owned the server. CI runners do not have that process, which is why CI stayed green. The registry's lock and state reread are sound; a reviewer tracedwithLockandsettleand found no ordinary interleaving that registers twice.Change. A
strayRequesthelper answers anything but a POST with 404, applied at the top of all six stand-in servers in this file (the sharedfakeMailand five inline ones). A new test sendsGET /tofakeMailand checks for a 404 and no recorded call; it fails without the guard with the sameSyntaxError.Not changed.
test/mcp-relay.test.tsandtest/wake-auto-t3.test.ts(lines 83, 174 and others) use the same parse-first pattern and can fail on the same GET;test/bridge-bridge.test.tsalready handles it. The wake-auto-t3 test that failed once under load in my earlier full run may be the same cause; I did not reproduce it.