Our application has initiated an NSURLSession data task, and we have received an initiation ID. However, Application not received callback on the subsequent activity: the task has not been requested, has not timed out, and no error callback has been received.
[06/17 09:29:40:559][ 0x282a7d8c0]<NSURLSession> Requested TaskIdentifier 120
2025-06-17 09:29:40.623337 +0530 nsurlsessiond SUBMITTING: com.apple.CFNetwork-cc-166-373-Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120>:A71666 default 2025-06-17 09:29:40.631280 +0530 dasd Submitted Activity: com.apple.CFNetwork-cc-166-373-Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120>:A71666 at priority 10 <private> default
Seen couple of rejection with <Must Not Proceed> for CPUUsagePolicy and MemoryPressurePolicy
2025-06-17 09:29:40.989360 +0530 dasd com.apple.CFNetwork-cc-166-373-Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120>:A71666:[ {name: CPUUsagePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[Max allowed CPU Usage level]: Required:90.00, Observed:95.00},]}} {name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}} ], FinalDecision: Must Not Proceed} default 2025-06-17 10:55:22.500277 +0530 dasd com.apple.CFNetwork-cc-166-373-Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120>:A71666:[ {name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}} ], FinalDecision: Must Not Proceed} default
And more an hour later then it throws with an error BUT NEVER indicated the same to client
2025-06-17 10:55:27.426549 +0530 WAVE PTX Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120> is for <<private>>.<<private>>.<120> default
2025-06-17 10:55:27.776951 +0530 nsurlsessiond Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120> summary for task failure {transaction_duration_ms=5147145, response_status=-1, connection=0, reused=1, request_start_ms=0, request_duration_ms=0, response_start_ms=0, response_duration_ms=0, request_bytes=0, response_bytes=0, cache_hit=false} default
2025-06-17 10:55:27.777096 +0530 nsurlsessiond NDSession <714296D7-20F9-4A0A-8C31-71FB67F39A56> Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120> for client <private> will be retried after error Error Domain=_nsurlsessiondErrorDomain Code=6 UserInfo={NSErrorFailingURLStringKey=<private>, NSErrorFailingURLKey=<private>, _NSURLErrorRelatedURLSessionTaskErrorKey=<private>, _NSURLErrorFailingURLSessionTaskErrorKey=<private>} - code: 6 default
Then It got resumed and says successful but never got any callback on the same to client
2025-06-17 10:55:28.877245 +0530 nsurlsessiond NDSession <714296D7-20F9-4A0A-8C31-71FB67F39A56> Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120> resuming default 2025-06-17 10:55:55.225456 +0530 nsurlsessiond Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120> received response, status 401 content K default 2025-06-17 10:55:55.250371 +0530 nsurlsessiond Task <D6B7595C-D94E-47F4-AE4F-A07DC1020929>.<120> finished successfully default
Please refer feedback for diagnose logs: https://feedbackassistant.apple.com/feedback/18173303
We would like to understand the real use case that would lead to this behavior.
The behaviour you’re seeing doesn’t strike me as strange. When you start a request in a background session, the system is free to schedule it as it sees fit. It’s very common to see long delays before the request completes. Specifically, it’s common for the request to be delayed until the next night, when the device is on mains power and has access to Wi-Fi.
The engine that drives this policy is complex, with many different inputs. It also changes as the system evolves. Given that, we’re unlikely to ever document it in the detail that you’re requesting. That is, what we’re talking about here are implementation details.
One input to this policy is whether the app that owns the session is in the foreground. The system typically boosts the priority of requests in such sessions. The error message you saw Error Domain=_nsurlsessiondErrorDomain Code=6 is not a real error, but rather an internal error that’s raised and handled as part of this priority boost mechanism.
You may also see the request start on the ‘wire’ and then spontaneously stop. This can happen, for example, if system conditions change (the user runs a game that needs a lot of memory) or if network conditions are poor (the session determines that the current progress isn’t worth the power cost and decides to defer the work). This is why it’s critical that your server support resumable transfers [1].
The only real guarantee here is that the request will either complete successfully or fail before the resource timeout interval (timeoutIntervalForResource). That interval defaults to 7 days, so there’s usually a few good opportunities for the request to run overnight during that time.
Additionally, we are looking for information on whether there is any delegate that could inform the client about this throttling.
Background sessions do not, in general, deliver detailed status updates to the delegate as they evaluate whether to run a request. The system tries to avoid resuming your app in the background as much as possible. That’s why, for example, background sessions don’t call the -URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler: delegate method.
Remember that every resume counts towards your resume rate limit. This is yet another implementation detail, although it’s an important enough concept to warrant coverage in the docs. See the Use background sessions efficiently section of Downloading files in the background.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Historically that was only supported for downloads, but that changed in iOS 17 when we added resumable upload support. For details, watch WWDC 2023 Session 10006 Build robust and resumable file transfers.