Skip to content

Retry Hashdown downloads and write them atomically - #22

Merged
CarlKCarlK merged 1 commit into
mainfrom
download-retries
Nov 14, 2026
Merged

CarlKCarlK merged 1 commit into
mainfrom
download-retries

Conversation

@CarlKCarlK

Copy link
Copy Markdown
Contributor

Hashdown._get_large_file (behind example_file, and FaST-LMM's sample data) made one urlopen call with no timeout or retry, writing straight to the final path. Today a macOS CI job failed on a single HTTP 503 while fetching sample files.

  • Retry network errors (DNS, resets, timeouts) and HTTP 5xx up to three times, waiting 1, 2 and 4 seconds. A 404 still returns False immediately; other 4xx errors are raised without retry.
  • 60-second connection timeout, so a stalled download retries instead of hanging.
  • Download to a temporary .part file and os.replace it into place only when complete; an interrupted download leaves the previous file (if any) untouched and no partial file behind.
  • New test_hashdown_retry.py (fake urlopen, no network) registered in the canonical suite.
  • Changelog entry under Unreleased.

Retry network errors and HTTP 5xx responses up to three times with 1, 2
and 4 second waits; a 404 still returns False at once and other 4xx
errors are raised. Give each connection a 60-second timeout, and
download to a temporary file that is renamed into place only when
complete, so an interrupted download cannot leave a partial file that a
later trust_local_files run would accept.

Add tests with a fake urlopen covering retries, give-up, 404 and 4xx
handling, and interrupted downloads.
@CarlKCarlK
CarlKCarlK merged commit 6703909 into main Nov 14, 2026
39 checks passed
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.

1 participant