I might have added this to the last node.done() topic, but it's been auto-closed.
The common clarification of when you need to use
node.done()is when you are doing async code within the node. Surely this is a case of "necessary, but not sufficient". Does the runtime parse the function node source to determine if timeouts, Promises, etc. are being used? I don't think so. AFAIK, to rule is that you need to call
node.done()if you are using
node.send()because the runtime assumes that you might be doing async code if you use
done()facilitates correct the enforcement of node timeouts.
Another use case for
node.send()in synchronous code is where you are bursting message content and issuing multiple variants of the same message.
send()handles all of the message cloning that is often needed transparently.
One case that I have been thinking about is where I am using
setTimeout()to issue deferred messages. The timeout function when it fires references its
nodevalue as a closed outer scope variable as part of JS closure magic, and hence it can issue the
done()on the correct
But what about the case where you want to implement a "reset" option to clear down the pending messages. You would need to issue the
done()for each relevant node to avoid timeout on these queued messages. I checked
89-delay.jsto see how the core
delaynode handles this, and it avoids this rathole by caching an
ourTimeout()function for each message.
Thanks for this