[miguel-heygen]

What

Follow-up to the cloud upload change that already merged: its progress and slow-server tests flaked, its retry loop was over the complexity limit, and the "same cut twice" rule compared bytes that vary from run to run.

• Two tries cut at about the same age (within 20%) now count as the same cut whatever bytes each got through; the byte count of a try varies with the link, the age of a fixed-age cut does not.
• The retry loop's cut decision moves into repeatedCut; the test server's body reading into drain, so fallow audit no longer flags putWithRetry and the test server.
• Progress is sampled on its own interval (putTimings.sampleMs, 1 s by default) and no longer on the stall interval, so a try that dies in under a second still reports the bytes it sent.
• The slow-server tests drain at a fixed rate whatever the chunk size and use a stall limit long enough that their own timing cannot trip it.

Why

upload.test.ts failed 1 run in 5 on the progress test and about 1 in 2 on the identical-cut test under load. Root causes: the stall watcher also drove the progress sampling (so a short try reported 0 bytes), the cut test compared byte counts across tries (kernel buffering varies), and the test server's drain rate depended on the chunk size the kernel handed it.

Size

A follow-up in the same module and its test, tied to one root (the flaky timing in the upload tests); nothing else touches them.

Test plan

• cd packages/cli && npx vitest run src/cloud/upload.test.ts: 20 passed, 6 runs in a row, on a clean checkout; oxlint and oxfmt clean on both files.
• fails without the fix: the cut test fails on main's upload.ts (it keeps retrying four times when the bytes differ between tries).
• fallow audit --base origin/main reports no new finding in the two files.

Size: a lone flake fix. It turns other PRs Windows-red and no open PR in the upload tests can carry it.

[heygengenesis]

Verdict: APPROVE · 0 blocker · 0 important · 1 nit · head d8d8c4db

The Windows red on #7356 (run 42355071130, engine-cli-1) was stops after a second identical cut instead of repeating the doomed try. On this head, Windows render verification and CI pass. The fails without the fix: line names that test.

• nit: with the byte check gone, two unrelated drops whose ages land within 20% of each other (say 10 s and 11.5 s on flaky Wi-Fi) now stop after 2 tries, with the message "this link cannot finish it". That trade looks intended (a fixed-age cut is the case it targets). Just noting that retries: 3 no longer protects that case.

Scope

Read the full diff (upload.ts, upload.test.ts). The default sample period is unchanged in production (min(1000, stallMs/3) either way). The tests still run on wall time against a real server. The PR doesn't claim a fake clock; it uses a fixed drain rate and a 5 s stall limit for the big file.

[miguel-heygen]

Thanks. The nit is a deliberate trade: two cuts that land at about the same age (within 20%) are treated as one fixed-age cut, because that is the pattern in the reports and each further try costs minutes on a link that cannot finish. The cost is what you describe: two unrelated drops at similar ages now stop after 2 tries instead of 4. A follow-up that sends the file in pieces retries each piece alone, so a drop then costs one piece and this stop rule matters much less.