Filed by the Account-2 read-only amplifier (2026-09-18, HEAD 246b710; coordinator + 3 read-only workers; static evidence only — no benchmark or script was run, per the read-only contract). Speculative — evaluate the idea; implementation is explicitly NOT the todo.
Finding
Every transient-failure retry restarts the part body from byte 0 (src/download.mjs:50 comment: "each retry restarts the body from byte 0"). Yet half the machinery for resuming already exists: download.mjs:74-78 sends Range: bytes=0- and accepts 206. A mid-body transient (reset/timeout on a 50 MB part after 40 MB) therefore re-transfers the whole part, up to 3×.
A resume shape would: re-hash the on-disk .part prefix locally (node cannot serialize crypto hash state, so the prefix is re-read — cheap local bytes vs network bytes), re-issue with Range: bytes=N-, append, and verify against the expected total (Content-Length / part.size / Content-Range accounting).
Impact
Saves re-transfer proportional to the failure position × retry count. Only matters for large parts and mid-body transients.
Why speculative
The frequency of mid-body transients on the real CDN is unknown — the sim receipts don't model them, and #20's motivating failures are not characterized by byte position. The complexity is real: hash-prefix re-read, 206 Content-Range vs expected-size accounting, .part bookkeeping across attempts.
Decision question (evaluate)
First instrument cheaply: log bytes received before transient failure in isTransientPartError call sites (or a debug counter) to learn the distribution. If mid-body transients dominate, evaluate the Range-resume shape above with the existing integrity tests; if failures are mostly early/connection-phase, close as declined with that evidence.
Filed by the Account-2 read-only amplifier (2026-09-18, HEAD 246b710; coordinator + 3 read-only workers; static evidence only — no benchmark or script was run, per the read-only contract). Speculative — evaluate the idea; implementation is explicitly NOT the todo.
Finding
Every transient-failure retry restarts the part body from byte 0 (
src/download.mjs:50comment: "each retry restarts the body from byte 0"). Yet half the machinery for resuming already exists:download.mjs:74-78sendsRange: bytes=0-and accepts 206. A mid-body transient (reset/timeout on a 50 MB part after 40 MB) therefore re-transfers the whole part, up to 3×.A resume shape would: re-hash the on-disk
.partprefix locally (node cannot serialize crypto hash state, so the prefix is re-read — cheap local bytes vs network bytes), re-issue withRange: bytes=N-, append, and verify against the expected total (Content-Length /part.size/ Content-Range accounting).Impact
Saves re-transfer proportional to the failure position × retry count. Only matters for large parts and mid-body transients.
Why speculative
The frequency of mid-body transients on the real CDN is unknown — the sim receipts don't model them, and #20's motivating failures are not characterized by byte position. The complexity is real: hash-prefix re-read, 206 Content-Range vs expected-size accounting,
.partbookkeeping across attempts.Decision question (evaluate)
First instrument cheaply: log
bytes received before transient failureinisTransientPartErrorcall sites (or a debug counter) to learn the distribution. If mid-body transients dominate, evaluate the Range-resume shape above with the existing integrity tests; if failures are mostly early/connection-phase, close as declined with that evidence.