[miguel-heygen]

What

The stalled-download tests' fake host no longer times out on a clock. Its idle timeout fires once the bytes the connection delivered are in the partial file, so the tests no longer race the disk.

Why

Tests on windows-latest: engine-cli failed on main and in the merge queue with resumes a download that stalls at the same byte count on every connection: "Download timed out after 10ms". When an attempt fails, the download counts its progress as the bytes that reached disk. The fake host's 10 ms timer could fire while a Windows runner's file write was still pending, so the attempt showed no progress and the download gave up, which is the test's other path. gives up when a retry brings no new bytes had the same race on its first attempt.

Related work

The tests came with the download-resume work (#6649, #6694). No change to download.ts.

How

stallingHost takes the partial file's path. Its fake request keeps the timeout callback and calls it once the file holds the bytes sent on that connection, checking once per event-loop turn. With a range-honouring host the partial file only grows, so that wait is exact. With a host that ignores the range, the retry rewrites from byte 0 and cannot show progress whenever the stall lands, which is the outcome that test asserts.

Test plan

fails without the fix: with every file write delayed 50 ms (a slow disk), main's two stalled-download tests fail; with this change they pass. On Windows runners main's version failed in #6744's run and in merge-group run 40881679648.

• The test still catches the bug it guards: with afterFailure's progressed -> continue rule removed, the stalled-download tests fail.
• download.test.ts: 31 of 31; the stalled-download group 3 runs in a row. Format, lint and commit hooks clean.

[heygengenesis]

Verdict: APPROVE · 0 blocker · 0 important · 0 nits · head d68e9113

Scope

• The fake host now waits on the same thing the code under test reads. writeBody's failure path waits for the file stream to close, then sets received = fileSize(tmp), so once onDisk sees the bytes the attempt counts them. For the host that ignores the range, both an early and a late timeout leave received ≤ 300, so the test reaches the same give-up path either way.
• Reproduced locally. With fs.open delayed by 50 ms (the stream still opening, its chunk buffered and dropped on destroy), main's two stalled-download tests fail with "Download timed out after 10ms" and this head passes. Delaying fs.write alone did not reproduce it, because a write already in flight finishes before close. Full file: 31/31.
• Required Tests on windows-latest (engine-cli included) and the rest of CI are green on this head.