Delay nodes mis-configured after upgrade to 2.2.0

After upgrading to 2.2.0 (from 2.1.x I think) then some my delay nodes show as mis-configured. I don't remember seeing that mentioned here already, apologies if I missed it. If I export and import it again the imported node also shows the problem, so hopefully it will also show the error for others.

        "id": "90e9c97c.3d1ee",
        "type": "delay",
        "z": "e2d1e6af.819db8",
        "name": "",
        "pauseType": "delay",
        "timeout": "1",
        "timeoutUnits": "seconds",
        "rate": "1",
        "rateUnits": "second",
        "randomFirst": "1",
        "randomLast": "5",
        "randomUnits": "seconds",
        "drop": false,
        "outputs": 1,
        "x": 146.5,
        "y": 216,
        "wires": [

Further to this, editing the node and making a trivial change fixes it.
It appears that it is the fact that the node is missing the property
"nbRateUnits": ""
that is the problem. Adding that in when importing fixes it.

It is common for a version upgrade of a node to result in nodes being marked as needing attention. In this case, because the node is part of the core, the upgrade to node-red also updated the node.

Often, all that is needed is to open the config panel for each node, press done and then redeploy. But of course, you should always check what change is needed.

I believe the intention is that it should not be necessary to manually intervene following an upgrade. The node should be capable of understanding the previous config, certainly that is what I aim for in my nodes. The only time it should be necessary to manually intervene would be if the new version was not capable of behaving exactly as the original did. In this particular case I suspect it is just a matter of defaulting the property to an empty string.

Indeed - a small regression introduced by - please raise an Issue

Issue raised -

As a core node, I've moved your issue over to the node-red repository - the link you've shared will redirect to the right place.

Sorry, that is where I meant to post it, after looking through the node-red-nodes repo to check it is not there. So I did the work and then ignored the outcome apparently. :frowning:

Well, that is a nice idea but not always feasible with major version changes :slight_smile:

In fact, I'm not even sure it is possible? If you have to add a new (required) property to the node, surely all of the nodes will need to update and you will then have to redeploy. You can set a default but I think that you still have to open them, press "Done" and redeploy. Or am I missing something?

For uibuilder, we are now at a stage where we occasionally have to introduce some fairly major breaking changes that require an update. I've even added a version check (not easy since there is no inherent mechanism to do that with nodes) so that I can give users some additional information via a node-red notification message when major changes happen.

If you mean the version of your node (not node.js or NR), I have been using
I think this was suggested by @knolleary in the Slack. I have not seen it documented anywhere, so I may be on thin ice.

Interesting, I just read the node's package.json :slight_smile:

The difficult part is for the Editor to know whether the node's version has changed. You need to save the nodes version when you deploy a node instance but you need to know the node's version every time you open the editor panel. Then you need to tell the editor whether a version change is significant. And you want to update the node version whenever you make another change to the instance settings but not otherwise or it gets annoying to users because the node gets marked as changed when the user hasn't changed it. A rather messy process all round.

But thanks for the reference. I clearly need to go and review the registry API and see if there is anything in there that could simplify any of my code. It is hard to keep it all straight!

PS: It looks like getModuleInfo returns the version and some other stuff and is probably the official way to do it.

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