This comment has been minimized.

This comment has been minimized.

@soulmercy
they said that my bug is a duplicated of another already opened bug, and that for privacy I can't have access to that.
They also said that I have visibility of the state in bug report. At the moment, the bug is still on open status. :(

This comment has been minimized.

I am using Xcode 10 GM and am able to reproduce the bug with the code you provided. Since there is not a solution yet I looking for work-arounds. Wrapping your get call inside a dispatch async after seems to prevent the issue. This only seems to work with a delay ... if you remove it then the error still occurs. Let me know what you think.

This comment has been minimized.

I am using Xcode 10 GM and am able to reproduce the bug with the code you provided. Since there is not a solution yet I looking for work-arounds. Wrapping your get call inside a dispatch async after seems to prevent the issue. This only seems to work with a delay ... if you remove it then the error still occurs. Let me know what you think.

This comment has been minimized.

edited

Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort"

I didn't use AFNetworking, but I reproduce same error code.

That Error occurred when attempting network communication at the timing of UIApplication.willEnterForegroundNotification.
I changed the timing to UIApplication.didBecomeActiveNotification, the problem no longer occurs.

I do not know it will be helpful, but I hope it will fix :)

This comment has been minimized.

edited

Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort"

I didn't use AFNetworking, but I reproduce same error code.

That Error occurred when attempting network communication at the timing of UIApplication.willEnterForegroundNotification.
I changed the timing to UIApplication.didBecomeActiveNotification, the problem no longer occurs.

I do not know it will be helpful, but I hope it will fix :)

Appreciate your help. In my case I have network calls while polling an endpoint that returns Okta MFA approval status. If the user briefly puts the app into background to respond to the Okta prompt from the Okta app, the url request gets cancelled with the error 53 above.
I noticed the same is true for any url request that does not complete while the app is active.
And this used to work fine with iOS 11 and 10 and built with Xcode 9.

This comment has been minimized.

So I ended up having to increase the delay time to .3 seconds. Maybe try that?
On Sep 21, 2018, at 7:24 PM, Gabor Sajo <notifications@github.com<mailto:notifications@github.com>> wrote:
I am using Xcode 10 GM and am able to reproduce the bug with the code you provided. Since there is not a solution yet I looking for work-arounds. Wrapping your get call inside a dispatch async after seems to prevent the issue.. This only seems to work with a delay ... if you remove it then the error still occurs. Let me know what you think.
DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
self.sessionManager?.get("https://reqres.in/api/users", parameters: nil, progress: nil, success: { (task, data) in
print("success")
}, failure: { (task, error) in
print("failure \(error.localizedDescription)")
})
}
This workaround doesn't seem to work for me.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#4279 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHQP_Yt15308eK1IbA3B8jbnSJU1LE4Rks5udYMRgaJpZM4WTO4P>.

-----
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance upon the contents of this message is strictly prohibited. Additionally, we kindly request that, if delivered to you in error, you please notify the sender immediately by email and that you delete this message and any accompanying files permanently from your system.
-----

This comment has been minimized.

I've received yesterday communications Apple side: they said that they are still investigating on the problem... the bug is apple side and they don't know when the issue will be solved.

By the way, I don't think that I can use any of the workarounds described here in my project.
I'm waiting for a solution apple side then ;)
I will update you as soon as possible when I'll have communications apple side :)

This comment has been minimized.

This comment has been minimized.

edited

The great guys from Alamofire suggested to use background tasks for network calls that may need to complete if the app is backgrounded.
I updated my code to do that on potentially long running tasks and it works well.

This comment has been minimized.

What happens on iOS 11 and earlier? iOS is still going to suspend the threads for the app unless a background task or download is started, so if a request is pending it can still end up timing out or aborting when the app is eventually foregrounded again.

This comment has been minimized.

Wrapping all requests in background tasks resolved the issue for me as well. I would still consider this a consider this a critical bug since Apple never provided any warning about this change in iOS 12.

This comment has been minimized.

So would it be possible for you to include some example code of how you wrapped the request in a background task. I can’t seem to do it right.
On Oct 5, 2018, at 10:11 AM, Jim Howell <notifications@github.com<mailto:notifications@github.com>> wrote:
Wrapping all requests in background tasks resolved the issue for me as well. I would still consider this a consider this a critical bug since Apple never provided any warning about this change in iOS 12.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#4279 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHQP_QsNe4i69ncQvfJpQFtc4NcJPTthks5uh3augaJpZM4WTO4P>.

-----
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance upon the contents of this message is strictly prohibited. Additionally, we kindly request that, if delivered to you in error, you please notify the sender immediately by email and that you delete this message and any accompanying files permanently from your system.
-----

-----
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance upon the contents of this message is strictly prohibited. Additionally, we kindly request that, if delivered to you in error, you please notify the sender immediately by email and that you delete this message and any accompanying files permanently from your system.
-----

This comment has been minimized.

I seem to be getting the same problem. Just to clarify, I'm not talking about ongoing requests being cancelled when the app goes into the background. I'm referring to requests being cancelled (or not even tried?) when performed too early, before the app enters the foreground. In OP's case in applicationWillEnterForeground, and in my case when handling deep links in the application delegate (Facebook Login callback or my own deep links).
Both problems described here might have the same root cause, but the flow is slightly different. 😉

This comment has been minimized.

I get same problem using NSURLSession directly from within applicationWillEnterForeground. Just in case this helps anyone, I found a simple workaround: prior to making any network calls from within applicationWillEnterForeground, discard and recreate your NSURLSession. Of course this will cause network connections to be recreated but I prefer it to using a delay-based solution that may behave differently on different devices.

This comment has been minimized.

Is it possible to have this background task wrapper in AFNetworking? It may be a parameter or by default?

I think I remember hearing that creating too many BG tasks can cause problems, and depending on the rate of requests it might be a bad default to automatically wrap every request in a BG task. I don't remember the source of that, and I don't know how many is "too many", so I realize this not a particularly helpful comment.