An example of URLSessionTaskMetrics from this failing request from a background upload of a 4mb file.. (Request) <NSURLRequest: 0x600002d2d3f0> { URL: https://{private} } (Response) (null) (Fetch Start) 2022-02-17 21:09:04 +0000 (Domain Lookup Start) 2022-02-17 21:09:05 +0000 (Domain Lookup End) 2022-02-17 21:09:06 +0000 (Connect Start) 2022-02-17 21:09:06 +0000 (Secure Connection Start) 2022-02-17 21:09:07 +0000 (Secure Connection End) 2022-02-17 21:09:09 +0000 (Connect End) 2022-02-17 21:09:09 +0000 (Request Start) 2022-02-17 21:09:11 +0000 (Request End) 2022-02-17 21:09:44 +0000 (Response Start) (null) (Response End) (null) (Protocol Name) h2 (Proxy Connection) NO (Reused Connection) NO (Fetch Type) Network Load (Request Header Bytes) 315 (Request Body Transfer Bytes) 2606217 (Request Body Bytes) 2604768 (Response Header Bytes) 0 (Response Body Transfer Bytes) 0 (Response Body Bytes) 0 (Local Address) 172.25.17.210 (Local Port) 51738 (Remote Address) {private} (Remote Port) 443 (TLS Protocol Version) 0x0303 (TLS Cipher Suite) 0xC02F (Cellular) NO (Expensive) NO (Constrained) NO (Multipath) NO 2022-02-17 13:09:53.089075-0800 Cup[81868:1972731] Task <FDDA3872-D8A7-4832-86A7-1F27537851E5>.<821> finished with error [-1017] Error Domain=NSURLErrorDomain Code=-1017 "cannot parse response" UserInfo={_kCFStreamErrorCodeKey=-1, _NSURLErrorFailingURLSessionTaskErrorKey=BackgroundUploadTask <FDDA3872-D8A7-4832-86A7-1F27537851E5>.<821>, _NSURLErrorRelatedURLSessionTaskErrorKey=(     "BackgroundUploadTask <FDDA3872-D8A7-4832-86A7-1F27537851E5>.<821>",     "LocalUploadTask <FDDA3872-D8A7-4832-86A7-1F27537851E5>.<821>" ), NSLocalizedDescription=cannot parse response, _kCFStreamErrorDomainKey=4, NSErrorFailingURLStringKey={private}, NSErrorFailingURLKey={private}}

In our case, these responses our definitely status 200's with json body. It doesn't happen with all requests only a minor but important chunk of users whom, once they received NSURLErrorCannotParseResponse they tend to get a lot of them. We attempt to retry these requests and that helps but does not resolve the issue. I have recently been able to reproduce the issue on iOS Simulator but simulating a transient/dropping Network connection with link conditioner. What I see is also in console reported as.. error 17:51:08.138859-0800 nsurlsessiond Task <86EF8AD5-8532-4D5F-B52F-4462078EA23A>.<525> HTTP load failed, 49316/0 bytes (error code: -1017 [4:-1]) We actually snooped CFNetwork binaries and found this string as _os_log_error_impl(rip - 0x14bb9b, *__os_log_default, 0x10, "%{public}@ HTTP load failed, %lld/%lld bytes (error code: %ld [%ld:%d])", &var_70, 0x3a); This may be a transient error leaking through a fall through case somewhere specific to background urlsessiond. What is supposed to happen for background URLSession is that transient errors such as lostConnection are never reported back to us and it only uploads when the network connection is good. I fear this is a bug in the network stack which is not recognizing (and retrying or not reporting) a transient error.