donnywals
commented
3 months ago Hi!
I don't think this behavior is (un)intended. That is to say, we don't attempt to either allow or prevent folks from doing this.
We could see if there's some way to detect that there's an existing URLSession with the same identifier already and then fail initialization for the second TUSClient so that you know to not make two instances for the same URLSession.
For now, I think clarifying in the docs is a good first step to at least make this behavior less unexpected!
Donny
Hello!
I've encountered an issue with file uploads when using a background URLSession with the same identifier across multiple TUSClient instances.
Steps to Reproduce Create two TUSClient instances using the same background URLSessionConfiguration (i.e., the same identifier). Start an upload using the second TUSClient instance.
Problem Description The issue arises because NSURLBackgroundSession holds a strong reference to its delegate (TUSAPI). When a new URLSession is created in the second TUSAPI instance, it does not override the delegate of NSURLBackgroundSession. And for some reason, the new URLSession uses the first TUSAPI instance as its delegate instead of the second one.
As a result, when starting an upload in the second TUSClient instance, the URLSession reports completions (func urlSession(_: URLSession:task:didCompleteWithError:)) to the TUSAPI belonging to the first TUSClient instance.
I'm unsure if this is intended behavior, but it seems we should not create multiple TUSClient instances when using a background session. It might be helpful to clarify this information in the documentation.