# Another Clarification on node.done()

**URL:** <https://discourse.nodered.org/t/another-clarification-on-node-done/83451>\
**Category:** General\
**Created:** [5 December 2023 22:45 UTC](https://discourse.nodered.org/t/another-clarification-on-node-done/83451 "2023-12-05T22:45:11Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![TerryE](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/terrye/32/65423_2.png) [@TerryE](https://discourse.nodered.org/u/TerryE)\
**Post date:** [5 December 2023 22:45 UTC](https://discourse.nodered.org/t/another-clarification-on-node-done/83451/1 "2023-12-05T22:45:11Z")

</div>

I might have added this to the last [node.done() topic](https://discourse.nodered.org/t/function-node-and-node-done/82467), 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 🙂

---

<div class="post-metadata">

**Author:** ![Lupin\_III](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/lupin_iii/32/67650_2.png) [@Lupin\_III](https://discourse.nodered.org/u/Lupin_III)\
**Post date:** [6 December 2023 17:47 UTC](https://discourse.nodered.org/t/another-clarification-on-node-done/83451/2 "2023-12-06T17:47:30Z")

</div>

Thanks for adding new consideration

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [4 February 2024 17:47 UTC](https://discourse.nodered.org/t/another-clarification-on-node-done/83451/3 "2024-02-04T17:47:40Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.