Test fails only beside others: test/stall-in-flight.test.ts #11969

I changed test/stall-in-flight.test.ts so it no longer assumes it is the only thing in the process's open-request set. The test passes alone and tsc is clean, but I never reproduced the sharded failure. The cause below is my inference from the code, not something I observed.

Cause. The last test starts a real server and asserts inFlight.size() === 1 and that the stall names exactly ["/mcp"]. inFlight in src/perf/live.ts is one process-wide set, and every test file in a shard shares it. A request left open by an earlier file, or background traffic to another file's server, makes those exact assertions fail. Run alone, the set is empty, so the test passes.

Fix. The test now records inFlight.size() before it starts and counts only what it adds:

• The size checks compare against that baseline.
• The stall must name /mcp, rather than equal ["/mcp"].
• The "stall reaching back before the request began" check compares against inFlight.since(now - 60_000) instead of expecting nothing.
• The system row is looked up by the fixed label /mcp (in flight).

The test was wrong here. I changed only the test, not the code under it. I did not run scripts/gate.ts or the wider suite; the forge's check does that on push.

Not done. Finding and fixing whichever file leaves a request open is a separate piece of work. I did not look for it, so the leak itself is still there.

Pushed to scout/11967-test-fails-only-beside-others-test-stall. To try it: bun test test/stall-in-flight.test.ts.

Closes #11967

I changed test/stall-in-flight.test.ts so it no longer assumes it is the only thing in the process's open-request set. The test passes alone and tsc is clean, but I never reproduced the sharded failure. The cause below is my inference from the code, not something I observed.

Cause. The last test starts a real server and asserts inFlight.size() === 1 and that the stall names exactly ["/mcp"]. inFlight in src/perf/live.ts is one process-wide set, and every test file in a shard shares it. A request left open by an earlier file, or background traffic to another file's server, makes those exact assertions fail. Run alone, the set is empty, so the test passes.

Fix. The test now records inFlight.size() before it starts and counts only what it adds:

• The size checks compare against that baseline.
• The stall must name /mcp, rather than equal ["/mcp"].
• The "stall reaching back before the request began" check compares against inFlight.since(now - 60_000) instead of expecting nothing.
• The system row is looked up by the fixed label /mcp (in flight).

The test was wrong here. I changed only the test, not the code under it. I did not run scripts/gate.ts or the wider suite; the forge's check does that on push.

Not done. Finding and fixing whichever file leaves a request open is a separate piece of work. I did not look for it, so the leak itself is still there.

Pushed to scout/11967-test-fails-only-beside-others-test-stall. To try it: bun test test/stall-in-flight.test.ts.

test/stall-in-flight.test.ts no longer assumes it is the only thing in the process's open-request set, and the gate now passes on my side. I pushed it, but the forge's check on that push hasn't reported back yet. I never reproduced the sharded failure, so the cause is inferred from the code.

Cause. The last test starts a real server and expected exactly one open request and a stall naming only /mcp. That open set is one object for the whole process, so a request left open by another test file in the same shard breaks those exact checks. Run alone, the set is empty and the test passes.

Change. The test now counts only what it adds:

• It records the open-request count before it starts and compares sizes against that baseline.
• The stall must name /mcp, rather than equal ["/mcp"].
• The check for a stall reaching back before the request began compares against inFlight.since(now - 60_000), so any older open request is allowed for.
• The system row is looked up by the fixed label /mcp (in flight).

Check failure. The check failed on two gate rules about my own edit, not on the test:

• Comment width: a comment line was 101 columns, so I rewrapped it.
• Real timer: two real-timer sleeps lacked a // real-timer: reason, so I added one to each.

bun scripts/gate.ts is clean, tsc is clean, and the test file passes alone (10 tests).

Not done. I did not find which other file leaves a request open; that leak is still there.

Only one of the four failures was this pull's. I fixed it and pushed, but the forge's check on the new push hasn't reported yet.

• This pull's failure: test/flake.test.ts rejected the wait-for-the-server poll in test/stall-in-flight.test.ts. The // real-timer: comment I added to the end of that while line stopped the rule from seeing where the loop ends, so it read the loop as one that runs out of time and carries on. The loop is now a braced block with the marked sleep on its own line, followed by the expect that checks the result.
• Other three failures: the log says test/flow-clock.test.ts, test/unused-exports.test.ts and test/timers-named.test.ts are red on main at 00d9cf3 as well, so they were not counted against this pull. I left them alone.
• Local results: bun scripts/gate.ts and tsc are clean, and test/flake.test.ts and test/stall-in-flight.test.ts pass (46 tests). I did not run the other three suites here.

The change itself is the same as before: the real-server test counts only the requests it adds to the process's shared open-request set. I still have not found which other test file leaves a request open.

test/stall-in-flight.test.ts is fixed, and I merged main into the branch and pushed. No review comments were on the pull, so I made no code changes beyond the merge.

• Why a merge: main had moved by 5 commits and the pull's check was marked stale. A rebase would have needed a force push, which is refused, so I merged instead.
• What I ran: after the merge, bun scripts/gate.ts and bun x tsc --noEmit came back clean, and test/stall-in-flight.test.ts passes (10 tests). I did not run the rest of the suite here. The forge's check will run it on this push.

What changed: the last test in test/stall-in-flight.test.ts starts a real server and used to assert exactly one open request and a stall naming only /mcp. The open-request set is shared by the whole process, so another test file in the same shard could break that.

• The test now records inFlight.size() before it starts and counts only what it adds.
• The stall must name /mcp, rather than equal ["/mcp"].
• The "stall reaching back before the request began" check compares against inFlight.since(now - 60_000).
• The system row is looked up by the label /mcp (in flight).
• The two real-timer sleeps carry // real-timer: reasons.
• The wait-for-the-server poll is a braced block, so test/flake.test.ts can read its verdict.

Why the test and not the code: the test was wrong to assume it was alone in the process. I never reproduced the sharded failure, so the cause is inferred from the code.

Not done: I did not find which test file leaves a request open, so that leak is still there. test/flow-clock.test.ts, test/unused-exports.test.ts and test/timers-named.test.ts were red on main at 00d9cf3, before this change. I did not run them after the merge.

Try it: bun test test/stall-in-flight.test.ts.

🤖 Generated with Claude Code