Closed sandervanhooft closed 3 years ago
@willemstuursma can you explain how #497 relates here, and if it still is considered part of the solution?
Related: #492 (timeouts reported)
Please expand the applicability of the retry logic to all request methods as long as the timeout happens within the CONNECT phase, the GET requests may be retried after sending the request body but I consider this an optimisation. The benefit of this change is increased reliability within the connect phase.
@rares-mollie that makes sense to me, let's focus on the CONNECT phase first.
My text above now reflects this.
Specifications
Describe the issue
Lately there have been some reports about api requests timing out. Mollie's development teams (@willemstuursma @rares-mollie) expect their DNS to be a significant factor.
While the problem is being addressed at DNS / infrastructure level at Mollie, this issue addresses mitigations that can be implemented within the mollie-api-php client.
There are two approaches to this:
I am mentioning both here because these approaches are interlinked.
1. Tweaking the Guzzle client options.
@rares-mollie has suggested to set the following on the Guzzle Options:
By setting the CONNECT_TIMEOUT to 2 we catch connection issues early on, before the call got through to the API. This ensures we are not getting timeout errors on a POST request that somehow still got through. Meaning we do not get false positive timeouts on calls that can mess things up in the API.
It also means that on
connect
issues, the retry scheme (when implemented) will kick in after 2 seconds instead of 10.2. Implementing a retry scheme on the Guzzle client.
I'll look into applying a retry scheme to the Guzzle client using the
RetryMiddleware
that ships with Guzzle. Probably will require a factory and wrapper class.This will impact
MollieApiClient::_construct()
, but it can be done in a backwards compatible way.When should the middleware be applied? (updated)
GET
,POST
,PATCH
,DELETE
) that result in a CONNECT timeout should be retried.GET
requests that connected ok but result in a timeout anyway should be retried.When should the middleware NOT be applied? (updated)
POST
andPATCH
requests.Testability
$decider
function which determines when the retry middleware should be applied