Skip to content

Avoid extra reconstruction request that returns 416#778

Open
assafvayner wants to merge 3 commits intomainfrom
fix/avoid-extra-416-reconstruction-request
Open

Avoid extra reconstruction request that returns 416#778
assafvayner wants to merge 3 commits intomainfrom
fix/avoid-extra-416-reconstruction-request

Conversation

@assafvayner
Copy link
Copy Markdown
Contributor

@assafvayner assafvayner commented Apr 4, 2026

Summary

  • Prefetch tasks are spawned eagerly during file download (at least two queued upfront in new()), but later tasks don't check whether an earlier task has already discovered the true end of file
  • This causes the last prefetch task to always send an unnecessary HTTP reconstruction request that returns a 416 Range Not Satisfiable
  • Fix: check the known_final_byte_position atomic at the start of each spawned task, and short-circuit if a previous task has already found the file end

Test plan

  • Verify downloads complete successfully without 416 errors in logs
  • Test with small files (covered by first prefetch block) and large files (multiple prefetch blocks)
  • Confirm no regression in download performance

Note

Low Risk
Low risk: small change to prefetch task scheduling that only short-circuits requests once EOF is already known, plus lockfile version bumps.

Overview
Avoids sending redundant reconstruction range requests that would return 416 Range Not Satisfiable by having each spawned prefetch task check known_final_byte_position and exit early when the requested start is already past the discovered EOF.

Also bumps xet-* crate versions from 1.4.0 to 1.5.0 in the WASM Cargo.lock.

Reviewed by Cursor Bugbot for commit 9ff4ed6. Bugbot is set up for automated code reviews on this repo. Configure here.

Prefetch tasks are spawned eagerly (at least two in new()), but later
tasks don't check whether an earlier task has already discovered the
true end of file. This causes the last prefetch to always send an HTTP
request that gets a 416 Range Not Satisfiable response.

Add a check at the start of each spawned prefetch task: before calling
retrieve_file_term_block, read the known_final_byte_position atomic.
If a previously completed task has updated it and this task's range
starts at or past that position, short-circuit with Ok(None).
// making this request unnecessary. This avoids sending a request that would
// return a 416 Range Not Satisfiable.
if prefetch_block_range.start >= known_final_byte_position.load(Ordering::Relaxed) {
known_final_byte_position.fetch_min(prefetch_block_range.start, Ordering::Relaxed);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this line is a no-op -- this only triggers if prefetch_block_range.start is already >= known_final_byte_position, which means known_final_byte_position is already at the min of the two.

Copy link
Copy Markdown
Collaborator

@hoytak hoytak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, with a minor correction.

@assafvayner assafvayner marked this pull request as ready for review April 6, 2026 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants