Allow Retry class to determine to retry based on response

[EnricoMi]

The Retry class allows library users to implement their own retry logic. The library calls into Retry.is_retry to determine if a request is to be retried based on the status code. Sometimes the status code is not sufficient to identify a retry-able error (#1445). The actual response, which includes the status code, the reason, response headers and payload, among others, is sometimes needed.

Replacing the is_retry method with is_response_retry allows users to get hold of the actual response. This change keeps is_retry to avoid breaking existing code.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (73953a0) 100.00% compared to head (958642e) 100.00%.
Report is 408 commits behind head on main.

❗ Current head 958642e differs from pull request most recent head 20170af. Consider uploading reports for the commit 20170af to get more accurate results

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #2500   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           25        25           
  Lines         2530      2532    +2     
=========================================
+ Hits          2530      2532    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[EnricoMi]

@sethmlarson to be clear: this is not intended for 2.0 but the next 1.x release. So I presume this should target branch 1.26.x, right?

[sethmlarson]

@EnricoMi We're not adding new features to 1.x as there won't be a 1.27 release. All new features must go into 2.0.

[EnricoMi]

So no quick fix. And a non-breaking fix is not required. What is the time horizon of the 2.0 release.

[sethmlarson]

@EnricoMi We don't have a date in mind, we're trying to finish these blocking issues before a release though.

[EnricoMi]

Should is_retry be marked as deprecated? Or shall both methods co-exist in the future?

[JannKleen]

@EnricoMi is there any update on this? I need my Retry-class to support a non-standard Retry header and having this merged would make life easier ;)

[ollie-bell]

Now that 2.0 is in pre-release, is this feature going to be available soon? Thanks!

[EnricoMi]

@sethmlarson rebased with latest main. Is this now good to go?

[EnricoMi]

This is sad...

[JannKleen]

@sethmlarson as someone interested in using it, is there anything missing in order to get this merged?

[ecerulm]

@EnricoMi can you resolve the merge conflict?

[EnricoMi]

@ecerulm conflicts resolved