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

Runtime Deployment Behavior

Node-RED utilizes a deployment mechanism that allows updating flow logic without a full process restart. During this cycle, the runtime invokes the stop method on existing nodes to clear timers, intervals, and event listeners before initializing the updated node versions.

Resource Cleanup Constraints

While the context API handles state preservation across deployments, the responsibility for resource cleanup falls on the node implementation. If a custom node fails to explicitly clear asynchronous listeners or intervals within its stop function, these resources may persist in the Node.js event loop despite the node being removed from the active flow.

Given the runtime's reliance on the stop method for lifecycle management in version 3.x and 4.x, it is unclear how the system handles nodes that omit this method or encounter errors during its execution.

• Does the Node-RED runtime provide a fallback mechanism to force-clear listeners for nodes that do not implement stop()?
• What is the expected behavior regarding memory reclamation for orphaned listeners when a flow is redeployed multiple times?