Monitor Function Node

I happens time and again that someone adds code in a Function Node which is error prone. The Node might work as expected in normale cases but if for example an input is not as expected the Node ends up in an endless loop (e.g. consuming all CPU).

At best I would like to monitor behavior like this (certain percentage of CPU usage or certain amount of time spent in any Node or ...) and in case any threshold is exceeded the watchdog should abort the run (and maybe even provide an error message why the run was aborted).

Any best practice how to do this?

I would say learn to use guards - check if an element exists, the type is it correct, avoid infinite loops with predefined iteration limits...

Well, the code is not written by me... let's assume the code is written by a customer and I simply want to protect the system (Node-RED) that in case something goes wrong, it does so gracefully.

I can suggest in this case to use link call with a timeout - this will trigger an error that you can catch with the catch node

As of Node-RED v3.1.x the function node has a timeout option that should kill a runaway loop


Dont do loops in function nodes - use the split and join nodes.

Have procedures in your organisation that require a code review before changes are committed to the mainline of your code version control system.

Does that start a separate thread that watches for a timeout?

No, it uses the node vm timeout and breakOnSigint options: adding timeout attribute to function node by k1ln · Pull Request #4177 · node-red/node-red · GitHub

  • timeout Specifies the number of milliseconds to execute code before terminating execution. If execution is terminated, an Error will be thrown. This value must be a strictly positive integer.
  • breakOnSigint If true, receiving SIGINT (Ctrl+C) will terminate execution and throw an Error. Existing handlers for the event that have been attached via process.on('SIGINT') are disabled during script execution, but continue to work after that. Default: false.

We offer Node-RED as an internal service and don't want to review "custom" code... the problem is that customers simply don't realize that it's because if their code and they simply complain that Node-RED is using all the resources...

On top of the suggestion i made:

You can also set a default for the function timeout functionTimeout in the Node-RED settings.js file

PR: Adding function timeout to settings file (#4265) by knolleary · Pull Request #4309 · node-red/node-red · GitHub

which means any function node added by the user will get a default timeout value. I would suggest 5 seconds is MORE than big enough.

1 Like

Many thanks. I will definitively look into this. Is this setting also released with 3.1 or was this available even before?

Was introduced in 3.1.0: release notes

1 Like

Though I'm going to tackle the current problem with the timeout setting (many thanks!) I would like to understand your recommendation to not use loops in Function Nodes... Can you elaborate why this is supposed to be an anti-pattern? At first sight split and join Nodes would seem like overhead (= slow down single flow execution)... is it mainly to make sure we don't do anything blocking on the event loop?

Exactly that.

While you may consider there is a cost to split/join, they permit the event loop to at least get a shout (unlike a hard loop in a function)

And, it is anti pattern as you say.

To be fair, if a user knows what they are doing and programs defensively with guards and limits, then there is less reason to avoid loops in a function node (small fixed size or limited iterations are not a major issue) but then this topic would not have started (and the timeout feature would not have been added) if we all programmed defensively.

One good reason to avoid function node loops is that blocking the eventloop will affect schedule/timer nodes. They WILL be blocked and WILL NOT execute on time (cron nodes, timed inject nodes etc).

1 Like

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