Skip to content

test: await the upload instead of expect().rejects in fetch-abort-stream-body.test.ts #45862

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dylan-conway wants to merge 1 commit into from
Closed

test: await the upload instead of expect().rejects in fetch-abort-stream-body.test.ts #45862

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion test/js/web/fetch/fetch-abort-stream-body.test.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -361,7 +361,7 @@ describe("aborting mid-body fails every reader of res.body with signal.reason",
await uploading.promise;
controller.abort(reason);
}
await expect(upload).rejects.toBe(reason);
expect(await settle(upload)).toBe(reason);

@claude claude Bot Oct 18, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 This edit routes the test around a runtime bug instead of fixing it, so CI stops catching a hang that bun test users still hit. await expect(p).rejects calls wait_for_promise (src/runtime/test_runner/expect.rs:513), which re-enters us_loop_run_bun_tick; the nested tick overwrites ready_polls, num_ready_polls and current_ready_poll (packages/bun-usockets/src/eventing/epoll_kqueue.c:536,550), so the outer dispatch loop at epoll_kqueue.c:260 exits early and the undispatched one-shot pipe polls are never read. Fix: make a nested tick preserve and dispatch the outer batch's remaining entries (or refuse to re-enter from dispatch), and keep a regression test for that path; the runtime defect itself is pre-existing.

Why this was flagged

Any user test that reaches expect(promise).rejects or .resolves from a socket/HTTP callback (a microtask continuation inside us_internal_dispatch_ready_polls) while another concurrent test awaits proc.stdout.text() on a Bun.spawn pipe. process_promise at src/runtime/test_runner/expect.rs:507-513 calls wait_for_promise, which loops tick()/auto_tick() (src/jsc/event_loop.rs:1141-1151); auto_tick calls tick_with_timeout (src/runtime/jsc_hooks.rs:1076) with no re-entrancy guard, and us_loop_run_bun_tick only bumps tick_depth (epoll_kqueue.c:482) before overwriting loop->ready_polls/num_ready_polls at epoll_kqueue.c:536 and resetting current_ready_poll at :550. When the nested tick returns, the outer for at epoll_kqueue.c:260 compares the nested counters and exits, so the remaining outer entries are dropped; a Bun.spawn pipe FilePoll is one-shot, so it is not reported again and the test's .text() never settles.

Verification: normal (the user-facing hang itself is pre-existing on base; what this change introduces is routing the one test that exposes it around the runtime bug, which the repository's review instructions name as blocking: "Never edit a test to route around a runtime bug it exposed" and "Fix bugs at the layer that owns the violated invariant, never where the symptom appears") — acknowledged in diff: the PR description says "This only stops the file from running into that behaviour of the event loop", i.e. the author states the runtime defect is left in place; that claim is accurate.

},
);

Expand Down
Loading