fix(retrievers): propagate non-404 HTTP errors from embedding download loop#1200
Merged
planetf1 merged 3 commits intoJun 4, 2026
Merged
Conversation
The embedding-parts download loop in download_mtrag_embeddings caught urllib.error.HTTPError to detect end-of-parts (404 = no more files). Since HTTPError covers all HTTP errors, a transient 429 or 5xx was treated as end-of-data, silently producing a truncated embedding set with no error raised. Fix: only break on 404; all other HTTP errors now propagate. Also adds _urlretrieve_with_retry to retry transient errors (429, 5xx) with exponential back-off before propagating. Closes generative-computing#1198 Assisted-by: Claude Code Signed-off-by: Nigel Jones <jonesn@uk.ibm.com>
planetf1
force-pushed
the
fix/hf-production-retry
branch
from
f0c2496 to
058ced3
Compare
planetf1
changed the title
planetf1
added
the
area/backends
Covers success, per-retryable-code retry, non-retryable 404 fast-fail, exhausted retries, and max_attempts=1 — all mocked so no network I/O. Assisted-by: Claude Code Signed-off-by: Nigel Jones <jonesn@uk.ibm.com>
… code Replace _urlretrieve_with_retry (which embedded application-level retry/sleep logic) with direct urllib.request.urlretrieve calls. Error handling is the caller's responsibility per project conventions. The only behaviour change: download_mtrag_embeddings now breaks only on 404 (end-of-parts signal) and propagates all other HTTP errors (429, 5xx) rather than silently treating them as end-of-data and returning a truncated result. Assisted-by: Claude Code Signed-off-by: Nigel Jones <jonesn@uk.ibm.com>
planetf1
changed the title
jakelorocco
approved these changes
Jun 4, 2026
Merged
via the queue into
generative-computing:main
with commit Jun 4, 2026
1e56745
13 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The embedding-parts download loop in
download_mtrag_embeddingsused a bareexcept urllib.error.HTTPError: breakto detect end-of-parts. SinceHTTPErrorcovers all HTTP status codes, a transient 429 or 5xx was silently treated as end-of-data — the download loop would stop early and return a truncated (or empty) embedding set with no error raised.Fix: break only on 404 (the genuine end-of-parts sentinel); re-raise everything else so the caller can decide how to handle it. One-line logic change — no retry, no sleep, no new helpers. Error handling is the caller's responsibility.
Testing
Unit tests in
test/formatters/granite/test_retrievers_util.py(all mocked, no network I/O):download_mtrag_corpus: invalid name raises, skips download if file exists, downloads when missing, propagates HTTP errorsdownload_mtrag_embeddings: 404 on first part raisesValueError, stops correctly after 404 on subsequent part, propagates 429/500/502/503/504 — parametrizeduv run pytest test/formatters/granite/test_retrievers_util.py -vpasses (11/11)CI green
Closes #1198