Another Clarification on node.done()

[TerryE]

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 send(), and 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 node value as a closed outer scope variable as part of JS closure magic, and hence it can issue the done() on the correct node instance.

• 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.js to see how the core delay node handles this, and it avoids this rathole by caching an ourTimeout() function for each message.

Thanks for this

[Lupin_III]

Thanks for adding new consideration