Bump com.android.tools.build:gradle from 7.4.2 to 8.0.0

[dependabot[bot]]

Bumps com.android.tools.build:gradle from 7.4.2 to 8.0.0.

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

> **Note** > Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[MilesV64]

Actually re-reading this issue seems to imply that this is the same problem just coming at it from a different angle - I don't really care about actively uploading in the background, but I imagine what's happening is it think it gets a network error and then tries to upload bytes the server already knows about? I guess I imagined that the server should just accept overwriting bytes it already has to avoid cases like this

[MilesV64]

Well that made me think "do network errors get handled at all" so I tried putting my phone in airplane mode and the upload immediately failed which is really undesirable behavior -- shouldn't the upload just pause until internet is restored?

[MilesV64]

According to the spec:

The tus protocol is built upon the principles of simple pausing and resuming. To pause an upload, you are allowed to end the current open request. The server will store the uploaded data as long as no violations against other constraints (e.g., checksums) or internal errors occur. Once you are ready to resume an upload, send a HEAD request to the corresponding upload URL to obtain the available offset. After receiving a valid response, you can upload more data using PATCH requests.

So I wonder if the issue is that after a PATCH failing due to a network error (IE backgrounding or dropping connection), the library is not HEADing the url before continuing to PATCH?

[donnywals]

Hi Miles, there's a lot here so let me respond to some of your key points first before addressing the main question in your issue.

Well that made me think "do network errors get handled at all" so I tried putting my phone in airplane mode and the upload immediately failed which is really undesirable behavior -- shouldn't the upload just pause until internet is restored?

This is something we could consider but we'd be at the mercy of the OS as to when exactly the upload would actually start. The upload would actually be in a "pending" state for about 24 hours before the OS considers the request impossible to make which might be too long for now.

If you want to have this behavior where a restored connection starts the upload it might be best if you implemented this yourself since this isn't something we have on the roadmap right now and my initial thought is that we will not be providing this since it would most likely be non-trivial to allow users to opt-out or tweak this behavior to their needs.

So I wonder if the issue is that after a PATCH failing due to a network error (IE backgrounding or dropping connection), the library is not HEADing the url before continuing to PATCH?

Possibly, I'll need to debug this scenario

Now for the actual issue at hand When you do a bunch of for- and backgrounding of the app the request should be cancelled after a second or so in the background since iOS would suspend the app entirely, including any pending network requests. In our upcoming release we allow requests to continue uploading in the background which should make your problem a non-issue.

However I will look into what's happening in the current SDK. It kind of sounds like it starts tripping over itself which of course isn't desirable; we want TUSKit to be robust and reliable. So I don't have any answers for you right now but I would like to ask you to see if a build with dw/bg-urlsession yields functioning results so we can at least verify that our next update would mitigate the issue at hand albeit by accident.

I will come back to this issue once I've done some testing on our current SDK to see what's happening exactly

[MilesV64]

Hey thanks a lot for the response, and yea sorry the issue covered a bunch of different topics as things came to me! Appreciate you addressing everything.

For network drops that makes sense to handle individually, as long as retrying doesn't cause the offset error. I can try to make some logic there and see if I do run into the offset error.

The background stuff looks exciting, I'll check it out! I suppose another solution for my particular use-case is simple pausing and resuming the upload when back/foregrounding, which is easy and makes sense to do myself rather than adding that to the library.

[Acconut]

I guess I imagined that the server should just accept overwriting bytes it already has to avoid cases like this

No, tus servers never overwrite data. The client must always continue the upload where it was left off.

I tried putting my phone in airplane mode and the upload immediately failed which is really undesirable behavior -- shouldn't the upload just pause until internet is restored?

I don't think this behavior is desired by every developer, so TUSKit should not behave like this by default. This should rather be left to implement by the developers themselves.

So I wonder if the issue is that after a PATCH failing due to a network error (IE backgrounding or dropping connection), the library is not HEADing the url before continuing to PATCH?

You are right. TUSKit should send a HEAD request before continuing to PATCH if it resumes an upload after a network interruption. @donnywals Do you think that there are cases where this does not happen? Do we need to look into this?