jasnell
commented
4 years ago Yep, this is actually intrinsic to the design of Promises and is really not something that we could do too much about automatically. The reason this happens is because in your example...
const recurse = async () => {
// ... function does some work ...
await someOtherFunctionCall()
// when execution returns to this function, V8's callstack isn't the
// long lists of recursive function calls
// ... function does some more work ...
// recurse!
recurse()
} The recursive call to recurse() is effectively a .then() handler for a Promise running in a separate call stack from the first part. The above code is roughly equivalent to...
someOtherFunctionCall().then(recurse)Node.js (actually V8) will execute the someOtherFunctionCall() and will reschedule everything that comes after it in the microtask queue, which is drained sometime after someOtherFunctionCall() exits, putting the two in completely different stacks. What your code here is effectively doing then would be roughly equivalent to doing something like...
function doItAgain() {
setImmediate(doItAgain)
}
doItAgain()Which would cause the function to be called over and over at the start of every event loop turn.
There's not much we can do about this in Node.js automatically because there might actually be legitimate reasons for having this recursion! The best approach is to have some additional mechanism for tracking, such as monitoring the number of times a function is called recursively...
const recurse = async (count = 0) => {
if (count > 10) throw new Error('boom!')
// ... function does some work ...
await someOtherFunctionCall()
// when execution returns to this function, V8's callstack isn't the
// long lists of recursive function calls
// ... function does some more work ...
// recurse!
recurse(count)
} 
astormnewrelic
addaleax
himself65
We've recently noticed/discovered that it's possible, via the
awaitkeyword, to create an infinitely recursive function that doesn't blow up the V8 stack. We're trying to find ways to identify and stop this sort of recursion.Is your feature request related to a problem? Please describe.
Normally, the
--stack-sizeoption of NodeJS prevents runaway recursion from becoming a problem. If a function recuses too deeply, the stack eventually grows too big, and node spits out an error and (appears to?) stop the recursion without exiting the program.However, with code like this,
--stack-sizeis no protection.We assume that although this is userland recursion, that behind the scenes the Node, V8, or libuv internals are handling the code after
awaitvia some sort of callback that doesn't have the original V8 stack attached. (We're not familiar enough with Node's inner workings to know for sure, so any corrections here would be appreciated).Depending on the work being done in the recursive function, or how/when/often it's called, this can create performance issues in an application or service that are hard to track down.
Describe the solution you'd like
The naive solution that we'd like is some sort of feature that allows us to limit the userland call stack depth. i.e. "if function recurses 1000 times something is probably wrong and we should -- do something". "Do something" is probably throw an error and stop the recursion, but we're not familiar enough with the internals to know if this is a viable solution or not.
The main goal of any solution would be to put node in a temporary state where we can easily identify and be notified then this sort of infinite userland recursion happens, and which function it is that's causing the recursion.
We're an analytics/monitoring company, and we often see this problem in our customer's applications. Our instrumenting code is often blamed for this recursion, when it is, in fact, just a poor interaction between our instrumenting code and our customer's application. Being able to have a feature that would let us identify and point to this recursion would be super helpful.
Describe alternatives you've considered
We first investigated the
--stack-sizeoption, but as mentioned, since V8's stack isn't growing this does not let us stop this sort of recursion.We've also asked our customers, and tried ourselves, to not write bugs. This has had mixed results.