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).
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.
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...
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?
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).
