Conversation
Remove the hand-rolled per-range retry loop (MAX_DOWNLOAD_RETRIES_PER_RANGE + RETRIABLE_DOWNLOAD_STATUSCODES) from _download_ranged. Transient failures are already retried by the urllib3 Retry configuration mounted on the connection's session (session_with_retries), so the DIY loop only added divergent behavior: different retry counts, different status codes (408/500/501 were retried here but not by the session), and OpenEoApiPlainError raised where the session raises RetryError. Fixes Open-EO#934
soxofaan
left a comment
There was a problem hiding this comment.
hi, thanks for contributing
some notes on you PR
- the retry regression test lives in test_job.py next to the other ranged download tests, and drives the public download_url method - the test content uses distinct chunks so each 206 range is unique - changelog entry moved to the bottom of the Changed section
|
Thanks for the review — addressed all four points in d6a57c6:
|
soxofaan
left a comment
There was a problem hiding this comment.
I also think the changelog entry needs alignment with latest master
| httpretty.register_uri( | ||
| httpretty.GET, | ||
| uri=API_URL + "/.well-known/openeo", | ||
| body=json.dumps({"api_version": "1.0.0", "endpoints": [{"path": "/credentials/basic", "methods": ["GET"]}]}), |
There was a problem hiding this comment.
this is not the correct body to return on /.well-known/openeo
I'd try with not mocking this request, I think that should still work
| httpretty.register_uri( | ||
| httpretty.HEAD, | ||
| uri=API_URL + "/dl/ranged.bin", | ||
| body=content.decode("latin-1"), |
There was a problem hiding this comment.
a HEAD request doesn't need a body, or am I misunderstanding?
| """#934: transient failures during ranged download are retried by the | ||
| standard urllib3 Retry of the connection's session, not a custom loop.""" | ||
| content = b"R4ng3d-D4t4" * 32 # 352 bytes -> one full and one partial 256-byte range | ||
| assert len(set(content[i : i + 256] for i in range(0, len(content), 256))) == 2 |
There was a problem hiding this comment.
I still find this content juggling a bit convoluted
why not return just "A" * 200 on the first GET, "B" * 100 on the second and check that you got "A" * 200 + "B" * 100 in the end?
| ) -> None: | ||
| # Retries on transient failures (429/502/503/504) are handled by the | ||
| # urllib3 Retry mounted on this connection's session (see | ||
| # session_with_retries), so no per-range retry loop is needed here. |
There was a problem hiding this comment.
I find this comment a bit misleading as it is (at this point) not guaranteed what kind of session or mounts are active
- drop the /.well-known/openeo mock: version discovery fails leniently - use plain 'A'*200 + 'B'*100 content instead of the chunk-uniqueness juggling - document why the HEAD registration still needs a body (httpretty constraint) - reword the _download_ranged comment: retry behavior depends on the session setup, which is not guaranteed at this point
|
Addressed all five points in 690e3d3:
|
Fixes #934
Removes the hand-rolled per-range retry loop from
_download_ranged. Transient failures are already retried by the urllib3 Retry configuration mounted on the connection's session, so the DIY loop only added divergent behavior: different retry counts, a different status-code set (408/500/501 retried here but not by the session), andOpenEoApiPlainErrorwhere the session raisesRetryErrorThe unused
MAX_DOWNLOAD_RETRIES_PER_RANGE/RETRIABLE_DOWNLOAD_STATUSCODESconstants are goneTested with
pytest tests/rest/test_download_ranged_retry.py tests/rest/test_job.py: 133 passed — including a new httpretty-based test proving a 503 on a range is retried by the session and the download completes