[Enhancement] Support for deciding if retry should happen based on request method and status code
Nicolai- opened this issue · comments
Support for deciding if retry should happen based on request method and status code.
Detailed description
Example some of our financial integrations, we would like to retry on 504(and others) for GET requests, as reading the data does not affect anything on the other side.
But for "Write" (POST, PUT, PATCH, DELETE) we do not want to retry, as we don't know what happened on the other side.
And here we should have some different handling, out of scope for this package.
Possible implementation
The new should_retry_callback
could have the request
added as a parameter, then it would be possible to decide if it should be retried based on our callback.
OR
Add method_specific_retry_on_status
to defaultOptions which would be an extension of the retry_on_status
.
Check it based on the request method in shouldRetryHttpResponse
which then also needs to have access to request
or request_method
after checking retry_on_status
Both solutions requires breaking changes, but it would make the package more flexible for future uses.
I can push a pull request, but I would like to know which solution I should target and you think would fit in the package.
Or I could do both, which would make it easy to handle different status codes based on request method.
The first change would also make 'should_retry_callback` more flexible.
Hi @Nicolai- , apologies for the delay. I think this is do-able with non-breaking changes. As of today's release of version 2.9.0, you are able to limit HTTP methods to retry on.
Unless I'm missing something, I believe that combining the retry_on_status
option and the retry_on_methods
option solves this use-case:
$stack = HandlerStack::create();
$stack->push(GuzzleRetryMiddleware::factory([
'retry_on_methods' => ['GET'],
'retry_on_status' => [504]
]));
$client = new Client(['handler' => $stack]);
$response = $client->request('GET', '/some-url');
You are not missing anything, we can definitely use the changes, they for sure solves what we were missing for retrying based on both status code and request method.
Looking back at my description, I might also not have explained our use case specific enough.
Our use case is something like.
Retry on 429 for all http methods
Retry on 503, 504 only for GET requests.
With the new release, I just add 2 instances 1 with each set of the rules.
Which is very clean and easy to use/read in the code, so works just perfect, and keeps it separated.
Thanks for the changes! :)