Retry only on certain request methods

[Ruben]

More of a feature request this is, but i would like to have an option present where i can limit retrying requests to certain HTTP methods.

Detailed description

So having a request option array that would allow us to only retry on let's say GET and DELETE but not POST, PATCH, PUT.

GuzzleRetryMiddleware::factory([
    'retry_enabled' => true,
    'retry_http_methods'  => ['GET', 'DELETE'], //default = null would retry all methods...
]);

Context

This is important because sometimes your POST and PUT requests change things that cannot be undone but GET requests in API's are fairly harmless and can be easily retried.

Tried implementing this myself on the should_retry_callback but unfortunatly the request that needs to be retried is not present in this context. Also something that would maybe come in handy one day..

Possible implementation

Not looked at possible implementation yet but maybe i will make some time to make a pull request if more people like the idea.

[Casey McLaughlin]

Hi @rubentebogt I've implemented this functionality in v2.9 (documentation here)

[Ruben]

Hi @caseyamcl this is amazing, thank you! Now i can remove code from my own projects that made this happen per request.

I do have one other question though, 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 the 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.

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 form the header after the above situation for instance.

PS: i can open a separate issue for this if you like.

[Casey McLaughlin]

Hi @rubentebogt that sounds like a order-of-checks issue.

Please do open a separate issue, and I'll have a look at it in the coming days.