Function node doesn't have timeout feature


the function node doesn't have a timeout feature but which is very well possible. Could i change the function node and make a pull request? Background is that if you create an endless loop in the function node then node-red doesn't respond and hard reset ist the only option.

I cannot believe that this is wanted behaviour.

Kind Regards

Kilian Hertel

Hi @KilianHertel

If an endless loop is introduced in a Function node that ties up the node.js event loop, how do you propose to time it out? The event loop is blocked so no timers will fire.

The vm library has a timeout attribute in runInNewContex => f.e. =>
const script = new vm.Script(skript);
const context = {
input: value,
parent: parentsource
script.runInNewContext(context, {
lineOffset: 0,
displayErrors: true,
timeout: 1000,
vm is what you use to run your function node.

You use this function:

ist has a timeout as well

You are quite right - completely forgot about the vm timeout option.

It would need to be configurable in the node; as it is perfectly valid to have a long running function node, as long is it hasn't tied up the event loop.

So should i create a pull request for this?

I did program this in an individual node, but this is more of a use case in a datamapper tool not a real function node.

I am new to contributing to node-red or open source in general.

If you leave the timeout on 0 the function node would have old behaviour.

... or unset/blank of course.

Also note the note on that page - "Using the timeout or breakOnSigint options will result in new event loops and corresponding threads being started, which have a non-zero performance overhead."

Starting another thread may of course be a benefit in some circumstances... (and not in others)... but we need to ensure the it cleans up properly if there is a re-deploy (stop/start) while this new thread is running.

In my test scenario I just ctached the error, which is thrown after timeout. I don't think that the process would continue after timeout, because this is actually the purpose of it. The timeout is there to kill the process after some time.

If you restart the server the threading of nodejs should be broken or should it not?:

I did run this on my Windows Laptop:

var vm = require("vm");
var i = 0
while (i < 10000) {
    var skript = 'var i = 0; while(1==1){i++;i--;}';
    const script = new vm.Script(skript);
    const context = {};
    script.runInNewContext(context, {
        lineOffset: 0,
        displayErrors: true,
        timeout: 4294967295,
    result = context.result;

It creates one blocked core. When i stop executing node, the core is free again, so no remaining threads i suppose.

Is this what you mean or didn't I understand that right?

Yes - mostly. and if you do a redeploy (which doesn't fully stop nodes). I think it should be ok - but we don't want orphaned threads lying around leaking memory. I'd expect the GC to clean up anyway but just in case. Timeout option looks useful.