Undefined behaviors for creating background session when another process (app extension) has a session with the same identifier

Originator:henriqueponde90
Number:rdar://33839325 Date Originated:08/10/2017
Status:DUPLICATE | OPEN Resolved:No
Product: Product Version:
Classification: Reproducible:
 
Area:
Foundation

Summary:
I've personally filed a rdar before (30450934) about how there are no guarantees on the ordering of the calling `getTasksWithCompletionHandler` and the calling of `didBecomeInvalidWithError`. In the case where a session is being used by another process.

Moreover, my teammate has filed another rdar on this (28352195) about the lack of documentation on what to expect `didBecomeInvalidWithError` to be called with. He also posted on the forums: https://forums.developer.apple.com/message/203635#203635 and got no reply. He actually has seen `didBecomeInvalidWithError` never even being called on iOS 9, different from iOS 8 where it always seemed to be called.

In that forums post (https://forums.developer.apple.com/message/203635#203635) he references another thread https://forums.developer.apple.com/message/131816#131816 , where eskimo claims we can look at NSURLErrorBackgroundSessionInUseByAnotherProcess, but that is not documented anywhere first of all.

The fact also that we don't get this callback (didBecomeInvalidWithError) at all times, and that the ordering of the callbacks is not guaranteed at all (see https://forums.developer.apple.com/message/199637) makes it really hard to work with this code.

Essentially, the asks are for a better documented experience of what to do when another process is using that session? What error to look for? What are the guarantees? Is `didBecomeInvalidWithError` guaranteed to be called (seems like the answers is no since iOS 9 and above). And even in the cases where it is called, is there a guaranteed ordering between `getTasksWithCompletionHandler` and the calling of `didBecomeInvalidWithError`?


Note: I've filled another rdar (33838468) of how the callbacks for NSURLSession are sometimes not called in the right queue, this seems to indicate a race condition to me. If that's the case, it could explain some of the bugs here. I talked to Steve in the labs and he said it could be related and that I should file this rdar again and reference all the previous ones.

Steps to Reproduce:
1. Create an NSURLSession in an Extension
2. In the main app, on foreground, try to create a session with that session identifier (to reconnect to tasks)
3. If the Extension's NSURLSession is still alive, then the main app's session will sometimes, but not always (rdar://28352195) send the delegate method `didBecomeInvalidWithError`.
4. If we call `getTasksWithCompletionHandler` on the main app, that block might be called before `didBecomeInvalidWithError` is invoked, if it's invoked at all

Expected Results:
We'd expect that `didBecomeInvalidWithError` is called always when the session is still in use and that the error to expect there is at least in the documentation. And when it is called in respect to when `getTasksWithCompletionHandler` returns to also be more documented.

Note: I've filled another rdar (33838468) of how the callbacks for NSURLSession are sometimes not called in the right queue, this seems to indicate a race condition to me. If that's the case, it could explain some of the bugs here. I talked to Steve in the labs and he said it could be related and that I should file this rdar again and reference all the previous ones.

Observed Results:
`didBecomeInvalidWithError` is not guaranteed to run at all times even when the session is being used by another process. And the variability with respect to the completion of `getTasksWithCompletionHandler` makes dealing with this code really hard.

Version:
iOS 9 versions and above

Notes:


Configuration:

Comments

DUPLICATE OF 28352195

Answer: Engineering has determined that your bug report is a duplicate of another issue and will be closed. The open or closed status of the original report your bug was duplicated to appears in a text box within the bug detail section of the bug reporter user interface. For security and privacy reasons, we don't provide access to the original bug yours was duped to. If you have any questions or concerns, please update your report directly at this link:https://bugreport.apple.com/.

By henriqueponde90 at April 13, 2018, 12:38 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!