Uppy stuck in "Encoding..." state with error `[Transloadit] Couldn’t find the file, it was likely removed in the process` about uppy HOT 5 CLOSED

That's odd, indeed. I looked at the Assembly status at https://api2.transloadit.com/assemblies/46140cb99b11473a8878b5dcfbd8e0a1 and there are a couple of things to note:

The Assembly is created with one upload to be expected, but two files are uploaded via tus for it. From the logs, it appears as if these two tus uploads were started at basically the same time. One possible explanation is a race condition in companion or tus-js-client, which causes duplicate uploads to be created. The two uploads could also explain why the upload URL changed.

That being said, I am not sure why the tus uploads include size: 0. That's incorrect and I will look into it.

The two files from the tus uploads were also successfully added to the Assembly. Logs from the servers also indicate that jobs for extracting the metadata completed, so the files were properly imported into the api2.

Although the uploads were finished and process by the api2, the assembly is marked as REQUEST_ABORT. I guess this is because bytes_expected !== bytes_received. The formed is calculated based on the size property of the uploads, which are incorrect for some reason.

yarn dev:with-companion and the Transloadit(tus) plugin,
Use for example DropBox, add a single file and upload it.

Do I need some secret credentials in my environment to do this? Can this also be reproduced when using something else than Dropbox?

from uppy.

Ok this is very interesting, thanks!

Do I need some secret credentials in my environment to do this?

yes. but maybe not for the URL plugin.

at least you need inside .env:

VITE_TRANSLOADIT_KEY
VITE_TRANSLOADIT_SERVICE_URL=https://api2.transloadit.com
VITE_TRANSLOADIT_SECRET
VITE_TRANSLOADIT_TEMPLATE
VITE_COMPANION_URL=http://localhost:3020
VITE_UPLOADER=transloadit

see also .env.example (although maybe not quite up to date)

Can this also be reproduced when using something else than Dropbox?

I believe so, and it can be reproduced with the URL plugin. I wanted to ttry to reproduce it on transloadit.com but that is currently broken due to a different issue

from uppy.

Thanks for the tips! I will wait what you and Merlijn discover. If there is a need for me, I can try to reproduce it as well :)

from uppy.

We found out what's the cause. After a refactor (#4734), Uppy now sends the "resume" event right after starting an upload. This calls this.tus.start():

the problem is that this.tus.start() has already been called by companion when the upload started (some hundred milliseconds before). Calling tus.start() twice causes tus-js-client to start the same upload twice, but produce a new uploadUrls the second time, sent back to uppy. I'm not sure if this is intended behaviour in tus-js-client (start the same upload twice in parallel for the same assembly), but we will workaround the issue by implementing a simple state machine to prevent calling tus.start() if we are already in the paused state. for fun we tried to call tus.start() 3 times back-to-back and indeed it uploaded the file 3 times to the assembly.

from uppy.

Now that you are talking about it, I remember that another user of tus-js-client also ran into duplicate uploads because of the same reason. I opened an issue in tus-js-client to implement protection against this in the future: tus/tus-js-client#659. Thanks for looking it this!

from uppy.