Open Murderlon opened 1 year ago
This is a bit of a tricky topic. From the tus perspective, the upload completed fine because all bytes were transferred and saved, as you correctly noted. As such, tus-js-client considers the upload successful. It does not have knowledge of the potential post-processing happening on the server-side.
3. Accept that we can't do post-processing and change the hooks accordingly.
I am not sure what you mean exactly here, but I agree that a proper solution must involve the server. Right now, tusd and tus-node-server do not preserve the result from any hooks. Maybe it is time to think about a more proper solution to post-processing than the post-finish and pre-finish hooks. Something which is retried by the tus server and stores a post-processing result (or error) which is then communicated back to the client. What do you think?
Sharing one approach:
In our custom server, automatic finalization is done with the last PATCH
, communicated via a response header (since TUS's PATCH unfortunately mandates HTTP 204 No Content
, thus forbidding us to return JSON), which is stored in tus-js-client
's onAfterResponse()
.
But like a hook, our finalization can fail after the saving of the bytes, thus leaving offset === length
and thus tus-js-client
considers the upload done and will send no further PATCH
.
This can be solved by detecting this situation in tus-js-client
's onSuccess()
whether onAfterResponse()
stored the mentioned success-indicating header; if not, one can send a manual 0-length PATCH
, or alternative use a non-TUS API to re-trigger finalization. We went with the latter.
It would definitely good to explicitly point out this hooks failure mode out in tus-js-client
's docs somewhere, as it seems to be a common error (I did not notice this at first, and coded a but that would keep unfinalized uploads with fully transmitted length stuck forever).
Perhaps in the docs of onSuccess()
?
Problem
When using the
pre-finish
hook from tusd or theonUploadFinish
hook from tus-node-server, which both allow an error to be returned and send to the client, will still result in a successful upload even when failed.Reproduction
tusd
hooks/pre-finish
Result with
@uppy/core
and@uppy/tus
(but the same happens with justtus-js-client
):tus-node-server
Same result.
Solutions
POST
if thecreation-with-upload
extension is used and onPATCH
if HTTP 500 is returned. The subpar thing with this is that it's indistinguishable from other HTTP 500 problems, which do warrant a retry, while a retry on a post-processing issue will likely keep resulting in the same result?