-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AF5: sometimes a request just disappears after internal createTask event #3396
Comments
Thanks for the detailed report. How many requests are we talking about before a failure occurs? And your server logs show that the request is actually made, it just never calls back to the I would suggest adding more logging, in addition to what's available through |
Failure to call the completion can happen relatively quickly - in the first 500 requests -- or it can take 10,000 or more. It's really unpredictable. It failed after 8,560 requests just now in a test. Server log shows request doesn't reach it. It almost looks like after createTask is logged, AF isn't auto-calling resume internally. I actually disabled auto-resume and manually called resume myself on each request after making it, just to explore that idea, but the problem still occurred. I've clarified the issue description to make it clear that the request doesn't seem to hit the server. So it look like the HTTP request isn't even leaving the iPad, but I'd need to use Wireshark or similar to make absolutely sure of that. Thanks for the state logging idea, I'll do some logging on that and update. |
Can you share the code you're using to enqueue requests onto the |
Hi, unfortunately I've run out of time with the client for investigating AF side, and they want to see what the app will do if we just use the usual iOS comms APIs directly. |
Hi again, we're still looking at AF. I've found that if I run our app in the profiler (using Allocations instrument), we get the issue really fast - within hundreds of attempts, not thousands. Does your example run ok in the profiler? Profiler shows the issue quickly for both Debug and Release modes. |
It would be useful if you posted your enqueueing code, otherwise I'm just guessing at how you're enqueueing all of those requests. I'll give it a try in Instruments. |
I've created a simple app which runs 10,000 requests in an |
I'll do it if I have time, but client has other ideas. They're asking me to submit a ticket to Apple support about this, against my advice. We all know the result of a TSI will be "Not our API, not our problem!" |
Have you solved it? I also have the same result. very occasionally and randomly. Do you use Alamofire 4 instead of 5? |
Hi, I forgot to provide a information that, I cancel a request everytime before session request( Base on our app). I don't know if this will help. |
Mark. I also have this question. |
Hi Team, Any update for this issue, we are commonly facing the same issue on iPhone 13 so please let us know how we can deal with and resolve it from our side.
|
NOTE: this is almost the same issue as #3392, but using plain HTTP and only one concurrent request, and we are not creating sessions per request -- just the one Session for all the requests now.
What did you do?
Our iOS app was using Alamofire 4 successfully; as part of upgrading to iOS14, we moved to Alamofire 5. Our application connects to a backend from iPad on wifi. Connection goes over local network to a locally hosted apache webserver.
Our application isn't doing anything very complicated. It now makes plain HTTP requests, and only one at time (that is limited by an NSOperationQueue with a concurrency limit of 1), using a single Session object which we keep as long as we want to make those requests.
Pseudocode for making our requests in AF5:
What did you expect to happen?
We expect all HTTP requests to result in the completion block being called.
What happened instead?
Very occasionally (like, once in thousands of requests), the completion block isn't called, and as far as I can tell, the request is never made to the server (since the logs are missing a corresponding entry around that time).
I attached an AF Logger and logged everything I could. From that I can see the following in the log for one of the 'dropped' HTTP requests:
The
AHAFlogger
lines are reporting Alamofire.Logger callbacks, so are a good sign of progress inside AF.After the above log lines, there are no more lines mentioning the URL
indexedDocument/64317069
, and the completion block for that request is never called. SodidCreateTask: task =
is the last we hear about the request from AF.When I check the server logs for recent requests, I can't find any trace of the request that seemed to disappear.
For comparison, here's the same verbose logging output for an HTTPS request that completed as expected:
Of note this is that we get more AF events after the
AHAFLogger didCreateTask:
. And of course the web server log shows these successful requests as 200 OK codes.Alamofire Environment
Alamofire version: 5.4.1
Xcode version: 12.3
Swift version: Swift 5 (as per Xcode build settings)
Platform(s) running Alamofire: iOS 14.2 on iPad
macOS version running Xcode: 11.1
Alamofire integration method: Carthage
Project language: mixed ObjC + Swift
Demo Project
Apologies, I don't have a demo project at the current time, but wondering if the above info is useful in seeing what the issue could be.
The text was updated successfully, but these errors were encountered: