Node-RED custom node stop() method and orphaned event listeners

The direct answer

No — the Node-RED runtime does not provide a fallback mechanism that force-clears timers, intervals, or event listeners for custom nodes that omit stop(). If your node doesn't implement it, the runtime simply has nothing to call, and any asynchronous resources the node created stay alive in the Node.js event loop after the flow is redeployed.

If stop() exists but throws partway through, the runtime catches the exception, logs it, and continues the redeploy. The node is treated as stopped for flow-replacement purposes, but anything not yet cleaned up before the throw remains active. There is no second pass.

Why the runtime can't clean up for you

This is a structural limitation, not an oversight. Node-RED has no registry of which setInterval handles, EventEmitter subscriptions, or open sockets a given node created. Node.js itself doesn't tag timers or listeners with an owner, so the runtime cannot selectively remove them without risking killing resources belonging to other nodes. Cleanup is therefore delegated entirely to the node implementation — this is well-established behavior across the 3.x and 4.x lines.

What orphaned listeners do across redeploys

Each redeploy instantiates fresh node objects, but orphaned timers and listeners from the previous instances keep firing. The practical consequences:

• Memory growth: every redeploy adds another live interval/listener holding references to the old node instance and its closure, so the old objects can never be garbage-collected. Growth is unbounded until the process restarts or hits an out-of-memory condition.
• Duplicate side effects: if the orphaned listener publishes messages, writes to a database, or calls an API, you get N copies of the side effect after N redeploys — often the first symptom people notice.
• Stale context: orphaned callbacks may reference the old node's context() or RED objects, producing confusing behavior that looks like a context bug but is actually a lifecycle bug.

The fix pattern

Track every resource you create and release all of it in stop(), wrapped so one failure can't skip the rest:

function MyNode(config) {
  RED.nodes.createNode(this, config);
  const node = this;

  node.interval = setInterval(() => { /* work */ }, 5000);
  node.onMsg = (msg) => { /* ... */ };
  node.on('input', node.onMsg);

  node.on('close', function (removed, done) {
    clearInterval(node.interval);
    node.removeListener('input', node.onMsg);
    done();
  });
}

Note that in current Node-RED the conventional hook is the 'close' event (node.on('close', ...)) rather than a literal stop() method — if your node truly has neither, nothing runs at teardown. The close handler receives a done callback; call it when cleanup finishes so the runtime isn't left waiting.

Verifying the behavior yourself

A quick experiment confirms all of this in a few minutes:

1. Create a test node that starts a setInterval logging a tick, with no close/stop handler. Deploy, then redeploy three times. You should see the tick frequency multiply — each orphaned interval is still firing.
2. Add a 'close' handler that clears the interval. Redeploy and confirm ticks stop after the first redeploy.
3. Throw an error at the top of the close handler before the clearInterval. Redeploy and check the Node-RED log: the error appears, the redeploy completes, and the interval keeps firing.

One caveat worth flagging for review: exact log wording and close-handler signature details have shifted slightly across major versions, so confirm against the version you run (node-red --version) rather than assuming 3.x and 4.x behave identically in the details.