Errors that happen in onProgress result in repeated HEAD requests

[tdewolff]

If there is an error in the onProgress callback, instead of reporting the error in the console, the JS client sends out HEAD requests (instead of PATCH requests) which is quite confusing!

Example:

      let upload = new tus.Upload(file, {
        endpoint: '/url',
        retryDelays: [0, 3000, 5000, 10000, 20000],
         metadata: {
          name: file.name,
          type: file.type,
          modtime: file.lastModified,
        },
        onError: function (error) {
          console.log(error);
        },
        onProgress: function (bytesUploaded, bytesTotal) {
          (null).method; // ERROR
        },
        onSuccess: function (e) {
          console.log('Download %s from %s', upload.file.name, upload.url)
        },
      });

[Acconut]

That's right, good point. We don't have errors that are thrown inside user callbacks well. This is likely not limited to onProgress, but is also the case for onSuccess, onError, and onShouldRetry. I wonder what the best way to handle those errors is:

• errors caught from user callbacks could trigger the onError, signaling that the upload was stopped because of this error. If no onError callback is registered, the errors is directly thrown.
• errors caught from user callbacks are logged to the console. While this allows the upload to continue, such errors could easily be missed, especially when an application produces a significant amount of logs, making debugging much harder. In addition, there would be no way for the user to handle those errors.

My first temptation would be to go with the first approach, which makes error handling more present. What do you think?

[tdewolff]

Thanks Marius for the quick reply! My initial expectation (adhering to the principle of least-surprise) would be that errors in callbacks are simply not caught/handled (and thus appear in the console as an error by default). Perhaps this would mean re-throwing the error. Otherwise, option one seems good!