-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lock on file never unlocked when request ends prematurely #697
Comments
Hi @Vija02 thanks a lot for reporting this. I'll need to investigate this further if it's not the case. |
Alternatively, we could add an event listener to the request object as soon as the request is received tus-node-server/packages/server/src/server.ts Line 152 in 7182c7b
Detect if the request is aborted and cancel the context with |
Was just going to say, maybe we also need to listen for |
Yep! makes a lot of sense to cancel the context on |
We should probably also pass the context into |
Thanks so much for the quick fix! Took me awhile to pin down the issue but all worth it. |
Initial checklist
Steps to reproduce
When a request ends prematurely (eg: when the user refresh the page), it could lead to the file never being unlocked and the promise hanging indefinitely. This only happens when the action occurs on specific timings.
Steps:
getUpload
function and artificially delay it for a few seconds.What's happening is that in
tus-node-server/packages/server/src/handlers/BaseHandler.ts
Line 181 in 7182c7b
The
req
is handed over to the pipeline which eventually resolves the Promise. However, if the request is already closed by this point, it never resolves nor rejects. I think adding a quickreq.closed
here will solve the issue?Separately, I also encountered an issue where if the resource is locked (like this issue) and the user tries to upload, the server will go into an infinite loop and eventually run out of heap memory. Fixing this issue should avoid that entirely but I thought it might be worth looking into as well (from a cursory look, it seems to be looping on trying to acquire the lock)
Not sure what the best fix here is (maybe just reject if it's closed?). If you give me a direction, I could create a PR
Expected behavior
It should handle the scenario when the request is over before it gets to that point
Actual behavior
The whole workflow stayed pending, leaving the lock on the file to remain forever
The text was updated successfully, but these errors were encountered: