NSURLSessionDownloadTasks sometimes contain nil values

Hello. I'm using NSURLSession (with background configuration) for downloading files. I have couple questions about NSURLSession workflow.

1) Sometimes, in very rare cases I noticed that in callbacks

Code Block
- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didCompleteWithError:(nullable NSError *)error
- (void)URLSession:(NSURLSession *)session downloadTask:(NSURLSessionDownloadTask *)downloadTask didWriteData:(int64_t)bytesWritten totalBytesWritten:(int64_t)totalBytesWritten totalBytesExpectedToWrite:(int64_t)totalBytesExpectedToWrite

task.repsonse / task.originalRequest has nil value. Unfortunately, I can't 100% reproduce it. I suggest that it can depends on some backend configuration or some edge case while file is downloading.
In docs these fields marked as nullable (so seems it's correct behavior), but explanation is very poor.

For example, for originalRequest it says

may be nil if this is a stream task.

But I'm not using stream task. I use
Code Block
[self.session downloadTaskWithURL:someURL];

and task usually contains originalRequest (at least when I created it).

2) In most samples, people (and I'm) using originalRequest as a unique key for tracking process (updating UI, moving downloaded file to documents directory, etc) and task.repsonse for detecting status code. So these fields are critical for proper management.
How to properly handle situation when these fields are nil? Can I just ignore it? Is it safe behavior?

3) Another interesting example which I noticed from different downloader implementations - save source URL and other metadata as task.taskDescription and use it instead of originalRequest in callbacks. Main advantage here that I can fetch tasks after app relaunch using

Code Block
- (void)getTasksWithCompletionHandler:(void (^)(NSArray<NSURLSessionDataTask *> *dataTasks, NSArray<NSURLSessionUploadTask *> *uploadTasks, NSArray<NSURLSessionDownloadTask *> *downloadTasks))completionHandler;

method. Is it a safe approach? I think to it in case when originalRequest is nil.

I think it’s reasonable to assume that, if you started a task with a request, it should be accessible via the originalRequest property. If that’s not happening, it’s definitely bug worthy. Please post your bug number, just for the record.

IMPORTANT It would be great if you could include a reproducible case in your bug report, but I understand that’s not feasible here. Without that, the CFNetwork team will need detailed logging in order to make any progress. Install the CFNetwork for iOS and Network Diagnostics for iOS profiles, both available on our Bug Reporting > Profiles and Logs, and then, when you see the problem again, take a sysdiagnose log and attach it when you create your bug report. Also, as part of your bug report highlight the specific task where you saw the problem.

Beyond that, using taskDescription to track your requests is fine. We recently clarified its documentation to make it clear that this is a supported use case.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Hello Quinn, thanks for your answer. I will try to reproduce issue on device (on the nearest future) with logs and fill bug report after.
NSURLSessionDownloadTasks sometimes contain nil values
 
 
Q