The following PR adds a new retry strategy allowing to bridge some async work to the retry mechanism of RealHTTP.
=> case afterTask(TimeInterval, RetryTask, RetryTaskErrorCatcher?) retries the original call after performing an async work.
Currently it is only possible to provide an other HTTPRequest to be performed before the retry. In a case where the request Authorization is handled by something else than a HTTP service, there is no way to interface with the Validator to create/refresh the authorization before the retry.
By adding a strategy that allows to provide an async Task, it is possible to perform work outside RealHTTP and inject whatever the user wants into the original request. Like with the existing retry with HTTPRequest strategy, the error that could be triggered by the async Task is not propagated to the original request, but a callback could be provided to at least "see" it.
Two specific unit tests were also added to cover this new strategy.
The following PR adds a new retry strategy allowing to bridge some async work to the retry mechanism of RealHTTP.
=>
case afterTask(TimeInterval, RetryTask, RetryTaskErrorCatcher?)
retries the original call after performing anasync
work.Currently it is only possible to provide an other
HTTPRequest
to be performed before the retry. In a case where the request Authorization is handled by something else than a HTTP service, there is no way to interface with theValidator
to create/refresh the authorization before the retry.By adding a strategy that allows to provide an async Task, it is possible to perform work outside RealHTTP and inject whatever the user wants into the original request. Like with the existing
retry with HTTPRequest
strategy, the error that could be triggered by the async Task is not propagated to the original request, but a callback could be provided to at least "see" it.Two specific unit tests were also added to cover this new strategy.