Avoid emitting error if upload was not done on closing request

I noticed that when a request ends, if at least one of the uploaded file streams was not consumed, an error is emitted. I’ve found out the hard way, that if you don’t subscribe to the 'error' event on the readable stream, the emission halts the node process and brings down the entire server.

FileStreamDisconnectUploadError: Request disconnected during file upload stream parsing.
    at IncomingMessage.request.on (/dev/project/node_modules/apollo-upload-server/lib/middleware.js:151:15)
    at IncomingMessage.emit (events.js:182:13)
    at resOnFinish (_http_server.js:564:7)
    at ServerResponse.emit (events.js:187:15)
    at onFinish (_http_outgoing.js:683:10)
    at process._tickCallback (internal/process/next_tick.js:61:11)
Emitted 'error' event at:
    at IncomingMessage.request.on (/dev/project/node_modules/apollo-upload-server/lib/middleware.js:149:32)
    at IncomingMessage.emit (events.js:182:13)
    [... lines matching original stack trace ...]
    at process._tickCallback (internal/process/next_tick.js:61:11)

This has the nasty side-effect of potentially allowing any GraphQL client to send a file under an unexpected field and tear down your server. I realize this after tracing a bug to the UI where the file: Upload field in the mutation was inadvertently being sent as attachment. The API server was dying, without any chance of recovering or catching the error.

You can try this using the apollo-upload-examples. Just change the expected file field in the singleUpload mutation to any other name on the UI and run the upload.

Is there any way of preventing this kind of behavior?

[twelve17]

@mike-marcacci I was handling errors on the graphql upload stream, but failed to do so on the other stream which was sending the data to the backend! So, thanks again for your help in steering me in the right direction. I owe you a 🍺!

[jaydenseric]

Again, the issue is not the current API, it’s that the API does not do what is is supposed to do under the hood. Yes, the right parser error events need to be listened, caught, and then thrown out of the middleware: https://github.com/jaydenseric/apollo-upload-server/issues/77. I just don’t have days and weeks up my sleeve right now to work on it, I am spread super very thin right now.

@mike-marcacci we could split out the tests in #81, which make up about 2/3rds of the diff, into a fast-tracked PR. The tests could be merged a lot quicker and might be helpful if others take a crack at solutions.