URLSession error -1005 "destroyReadStream" after resuming download task

Question

Created Dec ’17

Replies 1

Boosts 0

Views 1.1k

Participants 2

I have an app that uses a URLSession to download files from a server. It works fine on a wired connection and on most WiFi connections. On some WiFi connections however, if I stop and then resume() a download task (using the resume data), the download delegate's 'didCompleteWithError' is immediately invoked with error -1005. There is nothing wrong with the WiFi network when this occurs, server pings are all successful and have roughly the same durations as on a network where the failure never occurs.

Using CFNetwork Diagnostics, the first indication of a problem (difference from the success case) are these logs following a GET request. Unfortunately they don't indicate to me what might be wrong.

Is there anyone who might be able to explain why I'm seeing a "destroyReadStream", and what I can do to avoid or recover from it?

2017-12-13 11:45:38.928204-0500 MyApp[32126:5748989] TIC Read Status [13:0x604000165580]: 1:57
2017-12-13 11:45:38.928593-0500 MyApp[32126:5748989] CFNetwork Diagnostics [3:33753] 11:45:38.928 {
destroyReadStream: request GET http://<redacted> HTTP/1.1
          Request: <CFURLRequest 0x60c0001a0fc0 [0x7fffb2cf2570]> {url = http://<redacted>, cs = 0x0}
             sent: <CFNumber 0x1d937 [0x7fffb2cf2570]>{value = +473, type = kCFNumberSInt64Type}
         received: <CFNumber 0x37 [0x7fffb2cf2570]>{value = +0, type = kCFNumberSInt64Type}
        cell sent: <CFNumber 0x37 [0x7fffb2cf2570]>{value = +0, type = kCFNumberSInt64Type}
    cell received: <CFNumber 0x37 [0x7fffb2cf2570]>{value = +0, type = kCFNumberSInt64Type}
} [3:33753]

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’18

Error -1005 is

NSURLErrorNetworkConnectionLost

. You can read more about this error in general terms in QA1941 Handling “The network connection was lost” Errors.

In your specific case it seems that this error is caused by the network connection dropping unexpected. The error “1:57” error is something I explain in this thread.

The next step here is to look at a packet trace (per QA1176 Getting a Packet Trace). You need to determine if the dropped connection is coming in from the network (rather than being synthesised internally by the networking stack on the Apple device). I suspect it is, and I suspect that this is the result of some weirdness in a middlebox on that specific network, but a packet trace would tell you for sure.

If you retry the resume, what happens? If you get resume data in the -1005 error, you should retry with that; if not, you can retry with the original resume data.

Also, are you using a background session? If you (temporarily, just for testing) switch to a standard session, do you see the same problem?

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

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

0