Allow status predicates for retries#77
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #77 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 6 6
Lines 1001 1015 +14
=========================================
+ Hits 1001 1015 +14
🚀 New features to boost your workflow:
|
will-ockmore
left a comment
There was a problem hiding this comment.
Thanks for taking the time to put this together @mzl2233 .
Thinking about the exact semantics here, I think that adding a status predicate is probably more hassle than it's worth. It complicates the typing and breaks usage for anyone introspecting status_forcelist.
I was thinking about if we could add it as a separate parameter, but then we have to deal with which takes precedence. It's easier to avoid it entirely.
Apologies but I don't think we can accept this at the moment.
| assert HTTPStatus.INTERNAL_SERVER_ERROR in retry.status_forcelist | ||
| assert HTTPStatus.BAD_GATEWAY in retry.status_forcelist | ||
| assert retry.is_retryable_status_code(HTTPStatus.INTERNAL_SERVER_ERROR) | ||
| assert retry.is_retryable_status_code(HTTPStatus.BAD_GATEWAY) | ||
|
|
There was a problem hiding this comment.
Losing the ability to use in retry.status_forcelist would be sad.
Adds support for passing a predicate to
status_forcelistwhile preserving the existing iterable behavior. The retry status check now calls the predicate when one is provided, and the new regression test covers retrying 5xx responses without enumerating every status code. Verified withpython3 -m pytest tests/test_retry.py -q,python3 -m mypy httpx_retries tests, andgit diff --check.