Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upload hanging when using background URLSession #190

Open
andriyanovDS opened this issue Jun 6, 2024 · 1 comment
Open

Upload hanging when using background URLSession #190

andriyanovDS opened this issue Jun 6, 2024 · 1 comment

Comments

@andriyanovDS
Copy link

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.

@donnywals
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants