NSURLSessionTask never calls back after timeout when using background configuration

The only nuisance I see is didCompleteWithError callback is not invoked if the network connection is disconnected at middle or the URL is not reachable.

Right. That’s expected behaviour. Specifically:

• A background session will wait for connectivity before starting a request.

• In addition, for downloads, a background session will not fail the task if a specific request fails halfway through. Rather, the session will attempt to retry the request, supporting resume if possible.

These delays will continue until either the request completes or the task timeout fires (

timeoutIntervalForRequest

timeoutIntervalForResource

), and the default value for this timeout is seven days.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for your response!

These delays will continue until either the request completes or the task timeout fires (timeoutIntervalForRequest), and the default value for this timeout is seven days.

I already tried by setting timeoutIntervalForRequest but it did not work with background session configuration.I think I have to set up timeoutIntervalForResource instead timeoutIntervalForRequest but in my case, I can’t even use timeoutIntervalForResource property as I am not sure about the maximum time to complete the task. It completely depends on the resource size and network speed. If the file size is huge and network speed is low, it may fail. It would be great if I get any other solution or workaround for this.

https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/1408259-timeoutintervalforrequest

I already tried by setting

timeoutIntervalForRequest

but it did not work …

Right. That’s because I pointed you at the wrong property: I meant to say

timeoutIntervalForResource

. Sorry about that.

It completely depends on the resource size and network speed.

Indeed. This is one of the fundamental problems with timeouts, which is why our timeouts tend to be set to very large values.

It would be great if I get any other solution or workaround for this.

I’m not sure what you’re asking for here. Either you want a slow request to keep trying or you want it to fail. What else are you looking for?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I’m not sure what you’re asking for here. Either you want a slow request to keep trying or you want it to fail. What else are you looking for?

I want the slow request to fail. I am looking for a solution if no data is transmitted for certain time period then request should be failed. This is the actual behavior of timeoutIntervalForRequest but unfortunately, it will not work with background session configuration. So I was looking for the alternate solution.

Then, I tried timeoutIntervalForResource but the problem is, it will not reset the timeout value if data is transmitted.

Let say I set 3 minutes for timeoutIntervalForResource. If I try to download the large file which takes more than 3 minutes even in high-speed internet connection(Each data transmission interval is less than 3 minutes) but It will never get downloaded. I would like to solve this problem also.

In simple words, I am looking for something to simulate timeoutIntervalForRequest behavior in background session configuration.

To be clear,

timeoutIntervalForRequest

is honoured in a background session, it’s just that the background session will not fail the request after that timeout. Rather, it will hold on to the request and retry it at some point in the future, up to the limit imposed by

timeoutIntervalForResource

.

It sounds like you want to disable that automatic retry mechanism. There’s no direct way to do that, but you may be able to do it indirectly. One thing worth exploring is the HTTP method. I believe that the automatic retry will only occur for

GET

resources, and thus changing a method to one that’s not idempotent should prevent the retry. Of course this is only possible if you control the server in question.

This also sounds like a good opportunity for an enhancement request (-:

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"