Repository navigation
[Bug][CI]: the native passthrough reset fixture escapes as an unhandled error under load #5073
Description
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.
Activity
fix(test): raise the native passthrough reset from a requested pull (#…
fix(test): raise the native passthrough reset from a requested pull (#…
lidge-jun commentedon Sep 19, 2026
Fixed on
devby #5128 asf39ba5aad9.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,
devatecd3adae75, #5085, and #5106.The fix raises the reset from inside
pull()instead. The pull algorithm always observes its own promise —CallPullIfNeededattaches a rejection handler and routes the failure intoReadableStreamDefaultControllerError— so a throw frompull()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: 0is the second, weaker property, and the PR is careful to keep them apart: the queue is never stocked ahead of demand, sopull()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.