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

[iOS 12 Beta 11] NSPOSIXErrorDomain Code=53: Software caused connection abort #4279

Open
Gioevi90 opened this Issue Aug 30, 2018 · 36 comments

Comments

Projects
None yet
@Gioevi90

Gioevi90 commented Aug 30, 2018

I'm experiencing this issue in iOS 12 Beta 11 using last version of the framework (3.2.1).
The complete error localised description is:

HTTP load failed (error code: 53 [1:53])
2018-08-30 11:54:43.390749+0200 Background[2224:809685] Task <7CD7B0DD-2CE2-400D-AC02-D66C0F4E4847>.<7> finished with error - code: 53
2018-08-30 11:54:43.391271+0200 Background[2224:809125] Task <7CD7B0DD-2CE2-400D-AC02-D66C0F4E4847>.<7> load failed with error Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <7CD7B0DD-2CE2-400D-AC02-D66C0F4E4847>.<7>, _kCFStreamErrorDomainKey=1, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataTask <7CD7B0DD-2CE2-400D-AC02-D66C0F4E4847>.<7>"
), _kCFStreamErrorCodeKey=53} [53]
failure The operation couldn’t be completed. Software caused connection abort

The bug is easy to reproduce: you have just to put the application in background, wait for few seconds and restore it to foreground state.

I've reproduced it in a blank application, that I'm attaching there.

Feel free to ask if you have any doubts :)
Giovanni
Background.zip

@Gioevi90

This comment has been minimized.

Gioevi90 commented Aug 30, 2018

Note: to reproduce it you have to use a real device. I've never reproduced it into simulator

@Gioevi90

This comment has been minimized.

Gioevi90 commented Aug 30, 2018

Nevermind for it, it seems to be an apple bug, because I've reproduced it also using URLSessionManager methods.

I've opened a new bug here, if interested -> https://bugreport.apple.com/web/?problemID=43882930

@soulmercy

This comment has been minimized.

soulmercy commented Sep 7, 2018

@Gioevi90 Same problem with you. Got any reply from apple?

@Gioevi90

This comment has been minimized.

Gioevi90 commented Sep 7, 2018

@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. :(

@SlaunchaMan

This comment has been minimized.

Member

SlaunchaMan commented Sep 8, 2018

Thanks for reporting! We'll leave this open for now so people Googling the problem can find it more easily.

@siddharthsuneel

This comment has been minimized.

siddharthsuneel commented Sep 11, 2018

@Gioevi90 can you share the link of the already reported bug, so that we can also have a visibility of the state in bug report.

@Gioevi90

This comment has been minimized.

Gioevi90 commented Sep 11, 2018

@siddharthsuneel The link it's the same I've posted at the start of the discussion :) https://bugreport.apple.com/web/?problemID=43882930

let me know if you're able to see that :) (I've got some doubt, because it is related to my apple developer account, so for privacy concerns I think you won't be able to see that)

G.

@SlaunchaMan

This comment has been minimized.

Member

SlaunchaMan commented Sep 11, 2018

@Gioevi90 Other people won’t be able to see that link; people use Open Radar to get around that problem.

@SlaunchaMan

This comment has been minimized.

Member

SlaunchaMan commented Sep 14, 2018

@Gioevi90 Are you seeing this on the Xcode 10 GM?

@spenceratairstrip

This comment has been minimized.

spenceratairstrip commented Sep 18, 2018

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)")
		})
		
	}
@gabors

This comment has been minimized.

gabors commented Sep 22, 2018

Any luck finding a solution for this?
I have the same problem when using Alamofire. Also only happens on device and not simulator.
Wondering if this is an iOS 12 bug, or AFNetworking/Alamofire issue?

@gabors

This comment has been minimized.

gabors commented Sep 22, 2018

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.

@akasaaa

This comment has been minimized.

akasaaa commented Sep 22, 2018

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 :)

@gabors

This comment has been minimized.

gabors commented Sep 22, 2018

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.

@spenceratairstrip

This comment has been minimized.

spenceratairstrip commented Sep 22, 2018

@gabors

This comment has been minimized.

gabors commented Sep 22, 2018

Here is a simple test that demonstrates the problem.
When you run the test app with this view controller then immediately swipe to the phone home screen the data request is cancelled with error 53.

`class ViewController: UIViewController
{
let defaultSession = URLSession(configuration: .default)
var dataTask: URLSessionDataTask?

override func viewDidLoad()
{
    super.viewDidLoad()
    self.run()
}

func run()
{
    guard let url = URL(string: "https://httpbin.org/delay/5") else { return }
    print(url.absoluteString)
    
    self.dataTask = defaultSession.dataTask(with: url)
    {
        data, response, error in
        
        defer { self.dataTask = nil }
        
        if let error = error
        {
            print(error.localizedDescription)
        }
        else if let data = data,
            let response = response as? HTTPURLResponse,
            response.statusCode == 200
        {
            print("\(data.count) bytes received")
        }
    }
    dataTask?.resume()
}

}

`

@Gioevi90

This comment has been minimized.

Gioevi90 commented Sep 22, 2018

Thanks to all guys :)

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 :)

Thanks

@gabors

This comment has been minimized.

gabors commented Sep 22, 2018

Yeah this is a very serious bug IMHO.
Basically you cannot expect a network call to ever complete if the app os not in foreground.
Using background session configuration also fails BTW.

@damirstuhec

This comment has been minimized.

damirstuhec commented Sep 25, 2018

Seeing the same thing. @Gioevi90 please keep us updated.

@gabors

This comment has been minimized.

gabors commented Sep 25, 2018

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.

https://forums.developer.apple.com/thread/85066

@MikeWeller

This comment has been minimized.

MikeWeller commented Sep 26, 2018

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.

@MikeWeller

This comment has been minimized.

MikeWeller commented Sep 26, 2018

Relying to myself, I guess iOS 12 is more aggressively killing active connections/sockets even for very brief periods of suspending. https://developer.apple.com/library/archive/technotes/tn2277/_index.html (quite an old doc now) describes how sockets can survive backgrounding and suspending, but it seems something has changed here.

@JimHowell20

This comment has been minimized.

JimHowell20 commented Oct 5, 2018

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.

@spenceratairstrip

This comment has been minimized.

spenceratairstrip commented Oct 5, 2018

@dbeltram

This comment has been minimized.

dbeltram commented Oct 8, 2018

With Alamofire it's very easy to also add a retry logic in case of this error.

@JimHowell20

This comment has been minimized.

JimHowell20 commented Oct 8, 2018

here's the apple developer page on background execution:

https://developer.apple.com/library/archive/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html

So I just put this before every request is sent:

bgTask = [application beginBackgroundTaskWithName:nil expirationHandler:^{
// Clean up any unfinished task business by marking where you
// stopped or ending the task outright.
[application endBackgroundTask:bgTask];
bgTask = UIBackgroundTaskInvalid;
}];

And I put this in the completion block when every request returns:

[application endBackgroundTask:bgTask];
bgTask = UIBackgroundTaskInvalid;

Now requests finish when the app is moved to the background.

@spenceratairstrip

This comment has been minimized.

spenceratairstrip commented Oct 8, 2018

@flovouin

This comment has been minimized.

flovouin commented Oct 9, 2018

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. 😉

@dproton

This comment has been minimized.

dproton commented Oct 11, 2018

Retry failed requests seem works for me. I'm using Alamofire and it supports RequestRetrier to retry any requests before it really returns the error.

@ianlovejoy

This comment has been minimized.

ianlovejoy commented Oct 14, 2018

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.

@arbitur

This comment has been minimized.

arbitur commented Oct 19, 2018

I get this error too when I try to login with facebook sdk which takes me to the facebook app and then back and in the closure I make a call to my server to login with the facebook user.

I fixed temporarily by adding a 1s delay before calling my server to give the switch app animation time to complete which makes my app become active I assume.

@bar2

This comment has been minimized.

bar2 commented Nov 7, 2018

@Gioevi90 bug report is not available anymore, can you let us know what was the conclusion on the issue?

@ergunkocak

This comment has been minimized.

ergunkocak commented Nov 12, 2018

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

@danj-stripe

This comment has been minimized.

danj-stripe commented Nov 16, 2018

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.

@gabors

This comment has been minimized.

gabors commented Nov 16, 2018

Yeah the begin background task requires a UIApplication instance to be present, which may not be always practical. So wrapping every AF request is not a good approach IMHO.

@PraveenKommuri

This comment has been minimized.

PraveenKommuri commented Nov 17, 2018

@Gioevi90 Did you get any update from apple on this ? Ofcourse adding the delay fixed my issue.
Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment