I've used many web stacks over the years and not a single one defaults to blowing up like that. They all follow proper modularization... The framework cleans up objects that the framework creates, you deal with yours.
In any other framework forgetting to end the request would result in the request automatically ending when your code finishes. This includes Vert.x and Undertow which are just as asynchronous as Node(but also multithreaded).
Also how the hell does that leak memory? Is JS reference counting that bad? I've done some really stupid things in Java and C# but never leaked memory enough that it mattered.
But good point. How would you describe this item on error handling? How would you state it for the check list?
Do you mind explaining why the code causes this?
Usually error events propagate through piped streams, but that largely depends on the order in which the event handlers were defined.
Depending on the node web framework (express, ...) they may handle that differently and may have timeouts to cleanup.
I'd love to get a firm answer on this one.
For example, this code was from a guy in Stack Overflow:
What will that piece of code do? Leak the request object, the response object, including the underlying client connection... keep the connection open, leak memory... and at scale, make your server run out of sockets and memory. Then, when memory is low, swapping kicks in, overloading your CPU as well. In short, kills your machine with only a little 1 line of code mistake.There are less trivial ways of running into the same situation, but the lesson is that node.js is not a babyproofed technology and needs to be used with care.
This piece of advice is one of the most important, and the most overlooked/ignored in the node community.