Alamofire
Alamofire copied to clipboard
Retrying a cancelled request prevents the response block from executing
- [X] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.
What did you do?
- Called
Session.request()
, passing in a customizedRequestInterceptor
and retaining a reference to the returnedDataRequest
object.
let request = session.request(urlString, method: method, parameters: normalizedParameters, encoding: encoding, headers: headers, interceptor: interceptor).validate().responseJSON { response in
print("API Response: \(response.response?.statusCode ?? 0) from \(urlString)")
}
- Before the network request completed, I called
cancel()
on theDataRequest
instance I mentioned above. - The request cancellation triggered
retry(_ request: Request, for session: Session, dueTo error: Error, completion: @escaping (RetryResult) -> Void)
in my custom interceptor object. My interceptor's logic calledcompletion(.retry)
What did you expect to happen?
Above all, I expected the completion block passed to responseJSON
to be called.
I think it's arguable that the retrier shouldn't be called in this use case, especially if it won't result in the request actually being retried. But I haven't spent time considering the implications of that, so take it as you will.
What happened instead?
The completion block passed to responseJSON
was never called. Incidentally the request is also not retried.
Ultimately this is not a blocking issue for me. I simply added the following guard at the top of my interceptor's retry
function implementation:
guard !request.isCancelled else {
completion(.doNotRetry)
return
}
...and now the responseJSON
block is called as I would expect. That said, the behavior I originally described doesn't seem correct to me.
Alamofire Environment
Alamofire Version: 5.6.1 Dependency Manager: manual Xcode Version: 13.3.1 Swift Version:5.0 Platform(s) Running Alamofire: iOS macOS Version Running Xcode: N/A
Demo Project
N/A
Thanks for the report. Unfortunately we already check for cancellation at several points along the retry pipeline so I'll need to investigate to find an actual cause. Could you provide a reduced, executable sample that triggers the behavior you're seeing?
@jshier thanks for the quick response. Sorry, I don't have time to put together a sample project. I understand if that means it'll take longer for you to prioritize a fix. Since there's a very reasonable workaround, I'm going to employ that and move on.
I've been able to replicate this in a simple test case, so that's fine. I've pushed a fix to the bug/retry-cancellation
branch. Give it a try and see if it fixes your issue.
Fix for this was released in 5.6.3.