-
Notifications
You must be signed in to change notification settings - Fork 17
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
handle unpipeing, cancelling or destroying of busboy accordingly #81
handle unpipeing, cancelling or destroying of busboy accordingly #81
Conversation
Yes, it does look like the right solution. Can we cover it with tests though? |
tbh I have no idea how to simulate an aborted upload. |
Do you have any idea how to implement it? |
Looking through the tests, I would do it similar to the multipart-pause (
Btw, would you need to clear the event listener on busboy after the file has been succesfully processed? |
Any update on this one? |
I can try adding the test in a day or two if @Uzlopak doesn't do it first. |
If you call destroy again, it is handled as a no-op. https://nodejs.org/api/stream.html#writabledestroyerror Regarding the removal of the listener: Does it really matter? It either fails totally or it succeeds together. We dont pass an error object to destroy, so destroying the busboy-stream after we processed everything should not result in any additional errors. So if the FileStream got piped and processed it can be savely destroyed, imho. |
So what is now with this PR? |
Should fix fastify/fastify-multipart#315
Checklist
npm run test
andnpm run benchmark
and the Code of conduct