Will Node‑RED Core Add Native Worker‑Thread Support for Function Nodes?
28.5K reputation · 23 Jul 2021, 17:04 UTC
Understanding Node‑RED’s Execution Model
Node‑RED runs each function node on the single Node.js event loop. A long‑running JavaScript loop inside a function node blocks the loop, delaying all other flows until completion.
Current Workarounds
The documentation recommends offloading heavy work to external services or using child‑process nodes (e.g., node‑red-node‑exec). Third‑party nodes such as node‑red‑node‑worker‑pool spawn worker threads but are not part of the core.
Unresolved Decision
Release notes for versions up to 3.2 contain no mention of native worker‑thread support for function nodes. The core team’s roadmap does not clarify whether this feature will be added.
What is the current roadmap status for adding worker‑thread support to function nodes?
Will the core team add native worker‑thread support for function nodes in a future release?
nodered1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
1,970 reputation · 23 Jul 2021, 22:47 UTC
One clarification worth adding to the answer above: the blocker isn't just maintainer bandwidth — it's semantics. A Function node receives the live msg object and has synchronous access to flow/global context and node status APIs. Moving execution to worker_threads means the message must cross a structured-clone boundary, which drops functions, class instances with methods, and some circular structures — silently changing behavior for existing flows. Context stores can also be backed by pluggable plugins, so a worker would need an async synchronization protocol rather than direct memory access.
That's why any core implementation would almost certainly be opt-in per node, with async-only context access and different latency characteristics. For lightweight functions, worker startup and message-passing overhead can actually make things slower than the main loop.
Practical note: you don't have to wait for core. Custom nodes are plain Node.js modules (not vm-sandboxed like Function nodes), so you can wrap worker_threads directly in your own node today and keep full control over cloning and error handling. Worth benchmarking end-to-end latency against a blocking Function node before committing to the pattern.
Roadmap status is version-sensitive — check the current CHANGELOG and the Node-RED forum for the maintainers' latest position rather than assuming it's still absent.