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
@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!
Most helpful comment
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?