test(fetch-http2-client): deflake 'client RSTs on local error' via same-session barrier

[robobun]

Flake

fetch() over HTTP/2 > raw frame server > client RSTs the stream when it abandons on a local error fails on Windows (2019 x64, 2019 x64-baseline, 11 aarch64 — occasionally macOS ASAN) with:

expect(state.rst).toEqual([{ id: 1, code: 8 }])
- Expected: [{ code: 8, id: 1 }]
+ Received: []

Seen in 25+ of the last 65 completed BuildKite runs across branches (builds 48962-49247).

Cause

The subprocess script is:

try { await (await fetch(url, { tls })).arrayBuffer(); console.log("ok"); }
catch (e) { console.log("rejected", e.code ?? e.message); }

After handleResponseBody throws on the invalid gzip payload, the h2 client writes a 13-byte RST_STREAM(CANCEL) frame to the session's write buffer and flushes it to the TLS socket. But "flushed to the TLS socket" only means accepted into the BoringSSL/uSockets layer — not that it's on the wire. The catch block then prints and the script ends, so the event loop drains and the process exits.

On Windows, process termination does an abortive close (TCP RST) on open sockets, dropping anything still in the TLS write buffer / kernel send queue. The raw server's socket.on('data') never sees the RST_STREAM frame; state.allClosed() resolves on the abrupt close; state.rst is [].

Fix

Add a second fetch on the same pooled session after the error. The session survives a stream-level body-parse failure (only the stream is RST'd and removed; maybeRelease() pools the socket), so the follow-up request reuses it as stream 3.

RST_STREAM(1) is FIFO-queued ahead of HEADERS(3) on that one socket, so the 204 response arriving back at the subprocess proves the RST reached the server before the process exits. The test also asserts state.connections === 1 so the ordering argument actually holds (barrier rode the same socket).

This is the same pattern the neighbouring 303 redirect on a streaming-body POST RSTs the half-open upload stream test already relies on — there the RST for stream 1 is naturally followed by the redirect's follow-up GET on stream 3 before the subprocess exits.

Verification

• Full file: 58 pass / 0 fail, ×3 runs
• Fixed case in isolation: 20/20 pass

[robobun]

^{Updated 6:19 PM PT - Apr 29th, 2026}

❌ @robobun, your commit e39607f has 2 failures in Build #49257 (All Failures):

• test/js/node/watch/fs.watch.test.ts - pid 10575 segmentation fault at address 0x0�[0m on 🐧 25.04 x64
• test/js/node/watch/fs.watch.test.ts - pid 12158 segmentation fault at address 0x0�[0m on 🐧 3.23 x64
• test/bake/dev-and-prod.test.ts - code 1 on 🪟 2019 x64

---

🧪   To try this PR locally:

bunx bun-pr 29954

That installs a local version of the PR into your bun-29954 executable, so you can run:

bun-29954 --bun

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 247fe57f-3ae6-4c6c-af2d-e7228ee0ba2b

📥 Commits

Reviewing files that changed from the base of the PR and between e257f2d and e39607f.

📒 Files selected for processing (1)

• test/js/web/fetch/fetch-http2-client.test.ts

---

Walkthrough

The test file introduces a secondary stream "barrier" that responds with server-side HEADERS(204) for non-id===1 requests, while preserving the original gzip decode failure behavior for id===1. Subprocess logic is refactored to reuse a single TLS object and validate ordered stdout assertions across pooled HTTP/2 session requests.

Changes

Cohort / File(s)	Summary
HTTP/2 Raw-Frame Test test/js/web/fetch/fetch-http2-client.test.ts	Introduces secondary stream barrier with server-side HEADERS(204) response. Refactors subprocess logic to reuse TLS object and issue sequential requests. Changes assertions to validate ordered stdout sequence (rejected then 204), single connection reuse, and RST_STREAM(CANCEL) capture for stream 1.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: deflaking a test by introducing a same-session barrier pattern to ensure HTTP/2 RST frames reach the server.
Description check	✅ Passed	The description comprehensively addresses both required sections: it clearly explains what the PR does (fixes a flaky test with detailed root cause analysis) and how it was verified (58/0 pass across 3 runs, 20/20 in isolation).
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Review rate limit: 4/5 reviews remaining, refill in 12 minutes.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

LGTM — test-only deflake with a sound barrier pattern already used by the neighbouring 303-redirect test.

Extended reasoning...

Overview

This PR modifies a single flaky test case in test/js/web/fetch/fetch-http2-client.test.ts (client RSTs the stream when it abandons on a local error). The fix adds a second fetch on the same pooled h2 session after the error, acting as a delivery barrier so the RST_STREAM(1) frame is provably on the wire before the subprocess exits. The server handler branches on stream id (1 → bad gzip, else → 204), and assertions are extended to verify the barrier's 204 arrived and that state.connections === 1 (proving the barrier rode the same socket so FIFO ordering applies).

Security risks

None. This is a test-only change with no production code touched. The subprocess script is constructed by the test itself with a localhost URL; no new attack surface.

Level of scrutiny

Low. Test-only deflake, well-explained root cause (Windows abortive close drops buffered TLS writes on process exit), and the barrier technique mirrors the existing 303 redirect on a streaming-body POST test directly above it. The added connections === 1 assertion is a nice self-check that the ordering argument actually holds rather than masking a regression.

Other factors

No bugs found by the bug-hunting system. The PR description includes verification (58/58 pass ×3, 20/20 in isolation). The change is small, self-contained, and strictly tightens the test (it now also asserts the session was reused). No outstanding reviewer comments.

[robobun]

CI failure on windows-2019-x64-test-bun is unrelated to this change — it's test/bake/dev-and-prod.test.ts (DEV:dev-and-prod-12: hmr handles rapid consecutive edits timing out after 15s ×3), which appears in the flaky annotation of 22 of the last 40 builds across all branches.

fetch-http2-client.test.ts itself passed clean on every lane that's run so far, including the two Windows platforms where it was previously flaking:

lane	result
windows 2019 x64	58 pass / 0 fail (1.97s)
windows 11 aarch64	58 pass / 0 fail (1.86s)
windows 2019 x64-baseline	58 pass / 0 fail
debian 13 x64-asan	58 pass / 0 fail

Don't have write_builds scope to retry the failed shard from here.