unhandledRejection can cause file descriptor exhaustion

[mcollina]

Seeing an unhandledRejection in the output of a Node.js process is a code smell that a bug and a potential security vulnerability are within the codebase. It can trigger a very similar behavior of #28.
I have seen this happening, mainly because a lot of promise users thinks the error model of Node.js is similar to the one of the browser, and a missing error path will not cause problems down the road. This is very different in Node.js itself, because an error that is not handled properly can disrupt thousands of users.

A full example is available at https://github.com/mcollina/make-promises-safe#the-problem.

My solution is to always attach an unhandledRejection  handler which crashes the process.
This is very debated topic in the Node.js ecosystem, because it prevents a very common pattern of Promises, i.e. "fire and forget".

This is my opinion, and I added this issue because I think we should discuss about it.

cc @MylesBorins

[mikesamuel]

It seems like there might be a lot of problems of the form:

1. An HTTP request handler acquires some resources
2. Some promises are completed, some are not ... life happens
3. The HTTP response is fully flushed

It seems that the resources acquired 1 need not be scoped past (3).

It seems that we could reify a scope, and then associate a scope with a time slice.

Each time slice that starts with a handler handling an HTTP request, or that is scheduled (directly or indirectly) by that handler would have access to the same scope object.

Then we could close a scope at step 3.

That way, code that collects resources would have a scope to attach it to.

Is there something like this already?

[mcollina]

There are but none are performant (or reliable) enough. I would recommend to crash the program.
(this draws from my experience also in other platforms, I have never seen machineries like what you describe to be bug free and without overhead).

[mikesamuel]

It seems like, if the rate is low, then you've got a slow leak, but might be ok if you have a baby sitter.

If the rate suddenly spikes, that's useful telemetry for any DDOS detection systems.

If the rate rises after a push of a new version, then that might be significant to SREs.

It also seems, if there are commonalities in the stack at the point when the promise was created, then that should be exposed to developers.

If we could hand containers a default unhandled rejection handler and have them install it what should it do?