@uppy/tus does not wait for the findUploadsByFingerprint Promise to resolve before calling addUpload

[geekypradip]

Initial checklist

• I understand this is a bug report and questions should be posted in the Community Forum
• I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

No response

Steps to reproduce

I am using @uppy/core": "^3.0.4 , @uppy/dashboard": "^3.8.1 ,@uppy/tus": "^3.0.5 with react and I am uploading a single file of 400MB.

Flow Breakdown

Initial Start:

When the upload starts, Uppy calls findPreviousUploads to see if there is an existing session for the file.
Simultaneously, Uppy starts the upload and calls addUpload, which creates a new upload URL and stores it in the backend using the same fingerprint.

Resolution of findPreviousUploads:

If findPreviousUploads resolves after addUpload:

Uppy detects that there was already a previous session (e.g., uploadUrlOld) and switches to it by calling resumeFromPreviousUpload.
At this point, the server recognizes the uploadUrlOld and resumes uploading the file where it left off.

Interruption and Restart:

When the upload is interrupted and restarted:

Uppy calls findPreviousUploads again.
Since addUpload previously saved a new upload URL (uploadUrlNew) during the initial start, findPreviousUploads now returns uploadUrlNew.
Next Upload Resumes Freshly:

The upload resumes on the new upload URL (uploadUrlNew).
Since uploadUrlNew was never completed, the Tus server treats it as a fresh upload, starting from scratch.

The Problem

This flow causes resumability to break because:

Switching URLs Midway:

The Tus upload logic switches from the new URL (uploadUrlNew) to the old URL (uploadUrlOld) when findPreviousUploads resolves late. However, the new URL is already saved in the storage layer.
Repeated Fresh Uploads:

After interruption, findPreviousUploads returns uploadUrlNew as the most recent upload URL, leading to a fresh upload instead of resuming the old session (uploadUrlOld).

Root Cause

The root cause lies in the non-blocking behavior of Uppy when:

findPreviousUploads runs asynchronously, and Uppy starts the upload before waiting for it to resolve.
addUpload is called prematurely and saves a new upload URL in the storage backend.

Expected behavior

Wait for findPreviousUploads to Resolve Before Starting a New Upload:

Instead of calling addUpload immediately, Uppy should wait for findPreviousUploads to resolve. This ensures that no new upload URL is created unnecessarily when a valid previous session exists.
Defer the Creation of uploadUrl Until Necessary:

The creation of a new upload URL (via addUpload) should only happen when:
No previous upload is found, or
Resuming the previous upload fails.

Actual behavior

already mention in Steps to reproduce section