Meteor-Files
Meteor-Files copied to clipboard
Meteor instance crashes if underlying file is modified (size)
Meteor-Files v. 2.0.1 Meteor version: 2.1
Scenario: user uploaded a file, file was edited (growing in size) on filesystem, when serving file by .link():
I20210330-16:05:34.924(2)? [FilesCollection] [download(/cdn/storage/uploads/h9q7P2fYYKpY2GzAz/original/h9q7P2fYYKpY2GzAz.docx, original)]
I20210330-16:05:34.954(2)? [FilesCollection] [serve(/files/h9q7P2fYYKpY2GzAz.docx, original)] [200]
events.js:291
throw er; // Unhandled 'error' event
^
Error [ERR_STREAM_WRITE_AFTER_END] [ERR_STREAM_WRITE_AFTER_END]: write after end
at write_ (_http_outgoing.js:641:17)
at ServerResponse.write (_http_outgoing.js:633:15)
at IncomingMessage.ondata (_stream_readable.js:718:22)
at IncomingMessage.emit (events.js:314:20)
at IncomingMessage.Readable.read (_stream_readable.js:507:10)
at flow (_stream_readable.js:1007:34)
at resume_ (_stream_readable.js:988:3)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
Emitted 'error' event on ServerResponse instance at:
at writeAfterEndNT (_http_outgoing.js:696:7)
at processTicksAndRejections (internal/process/task_queues.js:85:21) {
code: 'ERR_STREAM_WRITE_AFTER_END'
}
Meteor dies, fixing file length in mongodb fixes the issue.
@Nidroide thank you for reporting this one.
This package takes care about content-length header and exception is expected to get thrown if file larger than it expected to be.
You have an option to disable that header with custom headers function.
But correct solution would be updating record in the mongodb after file is changed/edited. Package won't take care of it and you're responsible for correct record in the MongoDB. Another solution would be creating a file subversion. I'd also recommend to look at integrityCheck
option.
Let's keep this one open I'd definitely update codebase with catch
block to avoid exception.
Closed due to silence at issue owner end. Feel free to reopen it in case if the issue still persists on your end.