You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for this report. I am a bit split on this topic. On the one hand, I see the reason for why you would not want to modify the error after it has been raised. On the other, I can imagine there are situations where you want to have a reference and use it for further diagnostic measures. In addition, making a deep copy might cause more confusion for users because that is not what they would expect.
However, using uppy with tus-js-client as plugin will call abort on the request in the error case, which will set the readyState but also the status to 0
Maybe it is possible to fix this inside Uppy, so that abort does not get called? I could not think of a specific need for this call after an error has been raised. Could you bring this issue to the Uppy repository?
Then it calls the cleanup function resetUploaderReferences which aborts the tus upload. If it were not to call this function, I think it could cause memory leaks and upload continuing in the background even after error.
Maybe if Tus had a boolean property like isRunning or hasFailed (I couldn't find any such property), then we could check that property first and only abort if tus has not failed, e.g. in resetUploaderReferences:
Maybe if Tus had a boolean property like isRunning or hasFailed (I couldn't find any such property), then we could check that property first and only abort if tus has not failed, e.g. in resetUploaderReferences:
In #453 we talked about exposing such properties after an internal modification of tus-js-client to use a state machine. So I hope to add such properties soon, but there is no ETA available right now.
Describe the bug
tus-js-client/lib/error.js
Line 5 in 14c3634
req
andres
will be stored as a reference inoriginalRequest
andoriginalResponse
.This is quite cool, as we can access the response, get the status and do proper error handling in the client to show a human-readable error message.
However, using
uppy
withtus-js-client
as plugin will call abort on the request in the error case, which will set the readyState but also the status to 0(see: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/abort)
So I won't be able to read the status code in my underlying code.
Is it possible to store
req
andres
as a deep copy, for proper error handling?The text was updated successfully, but these errors were encountered: