-
-
Notifications
You must be signed in to change notification settings - Fork 132
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
fix: manually track if request is ended or not #272
Conversation
Thanks for bringing this up. What scenarios are you noticing this issue arise for? A correct GraphQL multipart request (e.g. single file upload) that if not for this bug, should have succeeded? Node.js v16 is tested quite thoroughly against most possible scenarios in GitHub Actions CI, and this particular issue hasn't come up yet. What specific versions of Node.js v16 are you noticing the issue with? I wonder if it's also buggy in Node.js v17, which is not tested yet in CI but all the tests pass locally for me.
Yea, I'm not sure either. Node.js streams timing issues can be tricky to figure out and reproduce sometimes. For this project we try get to the bottom of any mysterious issues before figuring out the most elegant solution, otherwise we might miss other locations in the code that have similar problems, and also with so many streams and events and things going on the code becomes a tangled mess pretty quick. I wasn't planning to work on |
Correct - it works correctly in Node 14 (I've never seen the processing error except in the correct cases where the request is cut off), but when upgrading to 16 (now that it's LTS) threw this error for every single upload, without ever being successful. Zero changes to any code in the client or on the server, just a pure node 14 -> node 16. And since manually tracking works, it points to some sort of |
I did a tiny bit more digging now - node |
I've been working on some updates the past few days, and have discovered 2 potential bugs (unrelated to this issue/PR). Gross Node.js streams stuff. Here is a suggestion as an alternative to this PR: graphql-upload/public/processRequest.js Lines 354 to 357 in 6158486
- request.once('close', abort);
+ request.once('close', () => {
+ if (!request.readableEnded) abort();
+ });
- request.once('end', () => {
- request.removeListener('close', abort);
- }); Because I can't reproduce the issue you've been experiencing, perhaps you could try that out and see if it works? I haven't used |
@jaydenseric thanks! Can confirm v13 works for us 🙂 |
When upgrading from node 14 to node 16, we started getting
Request disconnected during file upload stream parsing.
errors. Putting some log statements inside theend
andclose
event listeners shows that they are called in the correct orderUsing a boolean and manually tracking solves the issue.
I've tried to figure out if there were timing changes in the events in Node 16 without luck. I also don't know how to write a test for this...
For now I just use a patch to apply the change from this PR to our project. I don't really have the time to write a test, but I thought to open a PR in case it can be a start for a proper fix 🙂