Retry after with give_up_after_secs

[rubentebogt]

As promised; Enhancement questions:

1. in testing it became clear to me that when i receive a 429 or 503 with a Retry-After header that exceeds the give_up_after_secs setting it will always retry the request once more after the give_up_after_secs time has passed.

So request one comes back as 503 with a Retry-After of 3600 seconds, and the give_up_after_secs is set to 120 seconds, it doesn't fail immediately, it will always retry once more after 120 second, i wonder why that is? And also i would maybe like a setting that handles the Retry-After more strictly then.

You see on some platforms we pay per request, if another platform is down for half an hour then retrying after the give up time passes eventhough the header said not to doesn't make any sense then for us.

2. Also a nice addition in my opinion would be to have the Retry-After if present as diffInSeconds on the guzzle responseobject and therefor also in the RequestException object from guzzle. This wil allow us to interpret the header better using your code because it has already done so and release jobs in a queueing system back on the queue with the delay from the header after the above situation for instance.

3. Do you maybe know if this package is compatible with this one: https://github.com/spatie/guzzle-rate-limiter-middleware, it would be cool to have this rate limiter package and retry middleware working close togheter. If you don't no need to test this, i can do that myself and report.

The situation that i have in mind is that requests will only be retried if the rate limiter is not hit when presented with a 503 etc..

[rubentebogt]

@caseyamcl is there any update on this, we are still experiecing this issue? If needed i can provide more details and how we see that it's still happening.