Manually emitting 'error' events from Writable._write causes undefined behaviour due to this event name being used internally.
This happens in busboy if multipart headers are malformed or too long:
https://github.com/mscdex/busboy/blob/master/lib/types/multipart.js#L398
(the route is a bit circuitous but ultimately that code is invoked from within the _write handler)
In practice, the impact is that if this error is emitted, the writable never emits end / close, meaning that code like this never completes:
const myInput = Readable.from(Buffer.from('--foo\r\n: oops\r\n\r\ncontent\r\n--foo--'));
const handler = busboy({ headers: { 'content-type': 'multipart/form-data; boundary=foo' } });
handler.on('close', () => {
console.log('done'); // this is never printed even though busboy sets emitClose: true
});
myInput.pipe(handler);
Changing the event name (e.g. to 'warning') fixes the issue, and the close event fires as expected.
Note that other failure modes (e.g. for the input --foo\r\nx:) emit the error and also the close event (as expected), because the error is sent via the callback of _final rather than emitted directly.
Manually emitting
'error'events fromWritable._writecauses undefined behaviour due to this event name being used internally.This happens in busboy if multipart headers are malformed or too long:
https://github.com/mscdex/busboy/blob/master/lib/types/multipart.js#L398
(the route is a bit circuitous but ultimately that code is invoked from within the
_writehandler)In practice, the impact is that if this error is emitted, the writable never emits
end/close, meaning that code like this never completes:Changing the event name (e.g. to
'warning') fixes the issue, and thecloseevent fires as expected.Note that other failure modes (e.g. for the input
--foo\r\nx:) emit the error and also thecloseevent (as expected), because the error is sent via the callback of_finalrather than emitted directly.