Support plan
- which support plan is this issue covered by? (e.g. Community, Sponsor, or
Enterprise): Community
- is this issue currently blocking your project? (yes/no): yes
- is this issue affecting a production system? (yes/no): yes
Context
- node version: v10.16.0
- module (formidable) version: formidable@2.0.0-canary.20210216
- environment (e.g. node, browser, native, OS): node
- used with (i.e. popular names of modules): Koa
- any other relevant information: Using canary to leverage file streaming
What are you trying to achieve or the steps to reproduce?
When the request is aborted from the client, Formidable attempts to close every openedFile, but it appears this code path did not account for the new VolatileFile type, which has no path and no representation on the file system.
Specifically, in the _error handler, there's this snippet:
_error(err, eventName = 'error') {
// if (!err && this.error) {
// this.emit('error', this.error);
// return;
// }
if (this.error || this.ended) {
return;
}
this.error = err;
this.emit(eventName, err);
if (Array.isArray(this.openedFiles)) {
this.openedFiles.forEach((file) => {
file.destroy();
setTimeout(fs.unlink, 0, file.path, () => {});
});
}
}
The culprit being the setTimeout call to fs.unlink with an undefined file.path, since VolatileFile's don't have paths at all.
What was the result you got?
The node server crashes, which causes us production issues.
What result did you expect?
The request aborted handler should understand and handle VolatileFile instances correctly, and remove assumptions that there's a file on disk. Something simple like checking the type of file or for the existence of the path before attempting to close.
Support plan
Enterprise): Community
Context
What are you trying to achieve or the steps to reproduce?
When the request is aborted from the client, Formidable attempts to close every
openedFile, but it appears this code path did not account for the newVolatileFiletype, which has no path and no representation on the file system.Specifically, in the
_errorhandler, there's this snippet:The culprit being the
setTimeoutcall tofs.unlinkwith an undefinedfile.path, sinceVolatileFile's don't have paths at all.What was the result you got?
The node server crashes, which causes us production issues.
What result did you expect?
The request aborted handler should understand and handle
VolatileFileinstances correctly, and remove assumptions that there's a file on disk. Something simple like checking the type of file or for the existence of the path before attempting to close.