[Bug][CI]: the native passthrough reset fixture escapes as an unhandled error under load

[lidge-jun]

Client or integration

CI only; not a client-facing path.

Area

CI and release

Summary

tests/server/server-auth.test.ts line 4264 fails intermittently, and it does not fail as an assertion. The line is the fixture deliberately erroring its own stream:

(await source.promise).error(new Error("fixture upstream connection reset"));

The reported failure is that error surfacing as an unhandled error rather than being consumed by the code under test. When the runner is loaded, something that normally attaches to that stream in time does not, and the fixture's own reset escapes and fails the file.

It has now fired on three unrelated branches, which is why it belongs to the test rather than to the changes it interrupted:

Where	Head	Change under test
test 2/4	936a1c0f68 (#4989)	Responses post-header reset recovery
test 2/4	686b18063d (#5024)	request-owned main bearer pool ordering
macos 2/2	ecd3adae75 (dev)	freeform streaming grammar and SOCKS5 content-coding

The third is on dev itself with no pull request in flight. I attributed the first occurrence to #4989 in a review comment and was wrong about it; that comment is corrected.

The cost is not only the rerun. A test that fails for a reason unrelated to the change under test teaches reviewers to rerun red CI, which is exactly the habit that lets a real failure through.

Reproduction

Not reproducible on demand. It requires the surrounding suite to be under enough load that the reset arrives before its consumer is attached. No local verification was attempted; this repository verifies on hosted CI.

Version

2.59.0 (dev), observed at ecd3adae75.

Operating system

Ubuntu and macOS, GitHub-hosted runners.

Provider and model

Not provider-specific.

Logs or error output

4263 |       expect((await reader.read()).done).toBe(false);
4264 |       (await source.promise).error(new Error("fixture upstream connection reset"));
                                              ^
error: fixture upstream connection reset
      at <anonymous> (tests/server/server-auth.test.ts:4264:40)

Screenshots and supporting files

Not applicable.

Redacted configuration

Not applicable.

[lidge-jun]

Fixed on dev by #5128 as f39ba5aad9.

The diagnosis turned out to be more specific than "a race". Erroring a leaked stream controller from the test body raises the failure at a moment of the test's choosing, which is not necessarily a moment when anything is reading. Between the server sink's reads there is no pending read request to reject, so the rejection's only subscriber is whatever the runtime attaches next — and on a loaded runner the unhandled-rejection report wins that race. Nothing outside the stream can see or control that window, which is why it looked random and why it fired on heads that had nothing to do with it: #4989, #5024, dev at ecd3adae75, #5085, and #5106.

The fix raises the reset from inside pull() instead. The pull algorithm always observes its own promise — CallPullIfNeeded attaches a rejection handler and routes the failure into ReadableStreamDefaultControllerError — so a throw from pull() cannot become an orphaned rejection whatever the consumer is doing. That is the guarantee the new helper rests on, and it is absolute rather than probabilistic.

highWaterMark: 0 is the second, weaker property, and the PR is careful to keep them apart: the queue is never stocked ahead of demand, so pull() runs only in response to a read, and the stream is never errored before anything has attached to it. It is not a promise that a read request is still pending at the instant of the throw — a consumer that cancels in between removes its own request — only that the error is raised in response to demand and is consumed by the stream either way.

What the code under test sees is unchanged: one SSE chunk, then a mid-stream body error. The helper lives in tests/helpers/, so it is support-only and needs no test-layout entry.

CI was green on every leg at the exact head c2b33237d0. No local suite was run.

Worth noting for anyone tracking the other half of this class: the Cursor five-second stall from the same control-lane evidence was dispositioned separately in #5131, by putting the T04 watchdog on an injectable clock rather than by changing the production timeout.