fix(runtime): resume interrupted downloads - #2452
Conversation
✅ Deploy Preview for viteplus-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 269d64dafa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
f00c20e to
4a1b2d9
Compare
| let ranged = client | ||
| .get(url) | ||
| .timeout(timeout) | ||
| .header(reqwest::header::RANGE, format!("bytes={resume_from}-")) |
There was a problem hiding this comment.
Should we also use If-Range here with the ETag (or Last-Modified) from the original response?
Otherwise, if the resource changes between attempts, the server can return a valid 206 for the new representation, and we'll append it to bytes from the old one.
If-Range is designed for this case: if the representation has changed, the server returns a full 200, and our existing restart path can handle it safely.
Addresses #2449
A failed response body currently leaves partial bytes on disk, but the next retry recreates the archive and starts from zero.
This keeps those bytes and asks the server for the remaining range. It only appends after validating an exact
206 Partial Contentresponse and itsContent-Range. If a server ignores Range and returns a full200response, the partial file is truncated before the new body is written. Invalid partial responses fall back to a plain full request.One limitation worth calling out: nodejs.org currently answers these Range requests with a full
200, so Vite+ still restarts safely there. Mirrors that honor byte ranges can resume. The reporter's profile-specific failure was also caused by an interrupted0.2.6to0.2.9upgrade, which leftcurrenton0.2.6. That recovery is being verified separately in the issue.Tests cover:
200206response falling back safelyContent-Rangeparsing and boundsChecked with:
cargo test -p vp_js_runtimecargo clippy -p vp_js_runtime --all-targets -- -D warningsBest Regards, Tarik