Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Race condition saving files to S3
See original GitHub issueWhen saving using tus-node-server with the S3 backend the meta data gets saved in a .info file its metadata.
This file also gets used to reply to a HEAD request which uppy uses to determine if an upload succeeded (which it does after a PATCH resulted in 502?). So there is a race condition where tus-node-server actually failed in saving the file (hence the 502) but the HEAD call returns that there is a file since tus-node-server only check the meta .info file.
Any idea how to solve this? Would an extra call to S3 to check if the main file also exists be a solution?
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Hey, thanks for pointing me to tusd, will certainly have another look at it (gotta sharpen my go skill haha). Anyway the main issue is the ‘Complete Multipart Upload’ no being called correctly after an upload is done. I tried a few different options but couldn’t solve it reliably. I hope I can get tusd running, cheers!
As far as I know, tus-node-server has little protection against concurrent access which can result in these race conditions as you mentioned. I also don’t know how to solve this but we’re happy to accept a PR if you could supply one.
Alternatively, I would recommend you to consider using another tus server (such as the more mature https://github.com/tus/tusd) as we tus-node-server is in a bad shape right now (see https://github.com/tus/tus-node-server/blob/master/README.md).