Uppy: occasional 400/424s on deletion when multiple files are uploaded

Created on 1 Oct 2020  路  3Comments  路  Source: transloadit/uppy

hi again! i just wanted to share that about a month ago we started very occasionally seeing 404s on deletes where DELETE api calls are resulting in 423s being returned, followed a few seconds later by a 404. I'm assuming that this means that there's a 423 (locked) returned by the initial delete, so by the time it's reattempted a few seconds later, the deletion succeeds so it returns a 404 so we shouldn't be too worried.

We're only seeing this very occasionally, but I just figured I'd post in case you were also seeing this / thought this might need a further look. Thanks!

Here's the bread crumbs I've seen:

14:12:44 xhr
PATCH https://api2-waren.transloadit.com/resumable/files/id_here [0]

14:12:46 fetch
delete https://api2-waren.transloadit.com/assemblies/other_id_here [200]

14:12:46 xhr
DELETE https://api2-waren.transloadit.com/resumable/files/id_here [423]

14:12:46 fetch
GET https://api2-waren.transloadit.com/assemblies/other_id_here [200]

14:12:46 xhr
DELETE https://api2-waren.transloadit.com/resumable/files/id_here [423]

14:12:47 xhr
DELETE https://api2-waren.transloadit.com/resumable/files/id_here [404]

14:12:52 exception
Error: tus: unexpected response while terminating upload, originated from request (method: DELETE, url: https://api2-waren.transloadit.com/resumable/files/id_here, response code: 404, response text: upload not found
, request id: a8d6f3fd-9ba0-47f5-8859-db970c821568)
error

Bug

Most helpful comment

looks like this could be a tusd issue? The DELETE for an in-progress upload returns a 423 but appears to have succeeded anyways, so we get a 404 on the retry?

This does not look like a tusd issue. Instead this a feature of the Transloadit API2 :D When you stop an Assembly (by sending a DELETE request to the Assembly URL), tusd will automatically stop all associated uploads and delete all upload resources from the servers.

This explains the behavior in the logs above: When the DELETE request to the upload URL return a 423, the upload is still locked because it is being deleted. When the DELETE request return a 404, the deletion is over and the upload does not exist anymore.

Does that help?

All 3 comments

@Acconut looks like this could be a tusd issue? The DELETE for an in-progress upload returns a 423 but appears to have succeeded anyways, so we get a 404 on the retry?

looks like this could be a tusd issue? The DELETE for an in-progress upload returns a 423 but appears to have succeeded anyways, so we get a 404 on the retry?

This does not look like a tusd issue. Instead this a feature of the Transloadit API2 :D When you stop an Assembly (by sending a DELETE request to the Assembly URL), tusd will automatically stop all associated uploads and delete all upload resources from the servers.

This explains the behavior in the logs above: When the DELETE request to the upload URL return a 423, the upload is still locked because it is being deleted. When the DELETE request return a 404, the deletion is over and the upload does not exist anymore.

Does that help?

makes sense, thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

matthewhartstonge picture matthewhartstonge  路  3Comments

enneid picture enneid  路  4Comments

quetzyg picture quetzyg  路  3Comments

evanoberholster picture evanoberholster  路  3Comments

anushkamds picture anushkamds  路  3Comments