Open heebj opened 3 years ago
net::ERR_UPLOAD_FILE_CHANGED
If I understand this error correctly, the file that you are uploading has been modified or changed and therefore Chrome throws an error because it must be selected by the user again. I do not think there is much that tus-js-client can do against it. Maybe it is also a bug in Chrome or the Google Drive app where they do not retain the file long enough for the upload to be completed.
@Acconut thank you very much for your quick response! It helps a lot because I am a little helpless.
I just tested the same scenario with Firefox on Android and there it works. So it seems to be a problem with Chrome...
But why does it work if I upload a file with a classic file input without using tus? Does tus-js-client not use the same mechanism?
I just discovered this bug report in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1063576
But why does it work if I upload a file with a classic file input without using tus? Does tus-js-client not use the same mechanism?
tus-js-client uses exactly the same code for classic file inputs and files from Google Drive. tus-js-client could not even differentiate because it does not receive any information about where the file is located. Since you already found a relevant bug in Chrome, I assume this to be faulty behavior in their browser, which we cannot do much against.
My findings are consistent with others in that if the file is uploaded immediately it seems to work. However, if there's some delay between the time the file is selected and the time the file is uploaded, the
net::ERR_UPLOAD_FILE_CHANGED
occurs.
One user has written this in the Chrome bug report. @heebj What is your configuration for tus-js-client?
@SUNEELKUMAR94120 Please avoid posting empty comments.
@Acconut we are using the following configuration with uppy/tus:
{ endpoint: '/api/files/', removeFingerprintOnSuccess: true, autoRetry: false }
Which configuration could be used to change the delay?
@Acconut there is another possible Workaround mentioned in the Chrome bug report:
I am facing this problem on bandlab.com. After some trials, I noticed it still possible to get the array buffer and instantiate a new blob with it. It must be done synchronously on the "change" event of the input (no async/timeout as mentionned in https://bugs.chromium.org/p/chromium/issues/detail?id=1063576#c26).
Reading the array buffer takes some time though but so far it's my best shot to fix this problem. Both calling file.arrayBuffer() and using the FileReader API work. Tested on Chrome Android 85.0.4183.81, on my Samsung S8 (Android 9).
Can this somehow be of use to make a workaround in combination with tus-js-client?
Which configuration could be used to change the delay?
The delay occurs because tus-js-client has to send one request before it actually begins uploading the data. This can be circumvented by using the uploadDataDuringCreation
option: https://github.com/tus/tus-js-client/blob/master/docs/api.md#uploaddataduringcreation However, this feature must be supported by your server and might not work with pausing/resuming uploads.
Can this somehow be of use to make a workaround in combination with tus-js-client?
Yes, I think so. You could read the entire file into an ArrayBuffer/Blob and then pass this object to tus-js-client. I am not sure about the performace/memory impact but it might work and be worth a try.
This can be circumvented by using the uploadDataDuringCreation
Unfortunately this does not work either...
Unfortunately this does not work either...
What exactly do you mean?
Sorry for being so unspecific!
I tried the uploadDataDuringCreation
option as you suggested but without success. Chrome still throws the same exception.
Yes, I am able to reproduce the error, even with uploadDataDuringCreation. Apparently, the hint with eliminating the delay does not work in our case.
Frankly, I do not know what to do in this case. I don't have the time to dive deep into workarounds, so I would recommend you to report this bug to Chrome and/or Google Drive. This does not seem to be an issue in tus-js-client.
@heebj do you have any solutions?
Maybe this comment about cloning the file immediately before passing it to tus-js-client could be helpful: https://bugs.chromium.org/p/chromium/issues/detail?id=1063576#c79
Let me know if one of you wants to try this out and needs help.
Facing the same issue above and still no luck.
@MuhammadSulman Does this also happen when you use the demo at https://tus.io/demo to upload a file from Google Drive?
Describe the bug Our website uses uppy with the tus plugin (which wraps tus-js-client) to give users the possibility to upload files. We experience now an error when a user opens the website in Chrome on Android and tries to upload a file by choosing via the Android file selector a file which is located on Google Drive. There is no error when a file is selected from the local filesystem.
Then the following error occurs:
polyfills-es2015.10b81d008bc562125225.js:1 PATCH https://.../api/files/6c1538e598224cabad1e9bc86a3aba89 net::ERR_UPLOAD_FILE_CHANGED
main-es2015.62d4f7a5639510302e57.js:1 [Uppy] [14:09:47] Failed to upload Prov_01_Gorges de la Ceze.gpx This looks like a network error, the endpoint might be blocked by an internet provider or a firewall.
Source error: [Error: tus: failed to upload chunk at offset 0, caused by [object ProgressEvent], originated from request (method: PATCH, url: /api/files/6c1538e598224cabad1e9bc86a3aba89, response code: n/a, response text: n/a, request id: n/a)]
Expected behavior A clear and concise description of what you expected to happen.
Setup details Please provide following details, if applicable to your situation: