🎉 Node-RED 3.1.0-beta.3 released

News
1

:tada: It has been a couple moments, but we have now published the final (:crossed_fingers:) beta release of Node-RED 3.1.

Node-RED 3.x requires at least Node 14.x, but that has already reached its end-of-life. These days you should really be using Node 16 at least or even 18.

This is mostly a bug-fix beta with a couple small new things included. I hoping this gets us back on track to get 3.1.0 finally released.

The Change Log has the full list of changes.

If you haven't tried the previous beta releases, please check their release posts for details on what's included:

Note: if any issues are reported against the beta, we'll update this post to list them here. If you hit a problem, please do check back here before adding a comment.

Known Issues

  • JSONata value in Global Env Variables causes 2 warnings in debug sidebar (#4196)
  • catch and status nodes title not correct when set for Group Scope (#4197)

Group-level scope for the Catch/Status

The Catch/Status nodes could already be configured to handle specific nodes within a flow. They can now also be configured to handle just the nodes in the same group as them (or any nest groups).

This gives you more options for organising your flows and their error handling.

Lots of minor enhancements

Based on community feedback, we've made quite a few minor enhancements:

  • When merging groups, the style of the first selected group is the one that is used (previously it would use the 'earliest' group). It will also now merge any env-vars defined on the groups, rather than discard them.
  • When adding subflow ports, their nodes are added relative to where you have scrolled to in the workspace, rather than always in the top left corner

Dependency updates

We've updated lots of our core dependencies including the latest available Monaco editor.

The module underneath the HTTP Request node has been updated to a new major version; this picks up some useful security fixes.

Be sure to read through the Change Log to see what else is in there.

Installing the beta

If you want to try out the beta, you will need specify node-red@next when you use npm to update. Without the @next you'll still get 3.0.x

So on a Pi you'd do:

sudo npm install -g --unsafe-perm node-red@next

Reporting problems

If you hit any problems, please report them either as a reply on this topic, or in the #core-dev slack channel. Please do not post new topics to the forum regarding the beta as that could confuse users who are not using the beta.

Outstanding work

There are couple small PRs making their way through the system that will hopefully land in the next week. But they shouldn't warrant a new beta. So I'm hopefully we can finally get 3.1.0 released to the wider world in the next month.

We'll then be turning our focus on Node-RED 4.0, with the EOL of Node 14 having already happened.

7 Likes
2

Something peculiar about the group scoped catch and status nodes. Always shows :5 in the title. Bug :thinking: ?

chrome_yOcOUmdEFh

3

Yes - please raise an issue. The label property hasn't been updated to account for this new property

4

Anyone else see this?
Cannot name a group which contains a group.

Untitled 1
Untitled 1874×328 24.5 KB

Create a group or two, name them.
Make a new group enclosing them.
Attempt to name it - the Done button does not work.

5

Can you check the browser console please? May be the same issue I've seen: Max call stack exception editing group node (3.1.0-beta.3) · Issue #4198 · node-red/node-red · GitHub

6 
Uncaught InternalError: too much recursion
    get http://192.168.1.25:1880/red/red.min.js?v=3.1.0-beta.2:16
    isPlainObject http://192.168.1.25:1880/vendor/vendor.js?v=3.1.0-beta.2:2
    extend http://192.168.1.25:1880/vendor/vendor.js?v=3.1.0-beta.2:2
    extend http://192.168.1.25:1880/vendor/vendor.js?v=3.1.0-beta.2:2
    extend http://192.168.1.25:1880/vendor/vendor.js?v=3.1.0-beta.2:2
and so ad infinitum

Ah. But I did install beta3. Let's just reboot everything ...

Problem persists, error message different

Uncaught InternalError: too much recursion
    get http://192.168.1.25:1880/red/red.min.js?v=:16
    extend http://192.168.1.25:1880/vendor/vendor.js?v=:2
    extend http://192.168.1.25:1880/vendor/vendor.js?v=:2
    extend http://192.168.1.25:1880/vendor/vendor.js?v=:2

Presumably it is the same problem @Steve-Mcl , messages different from yours due to different browser? (FF113)

7

Yeah, call stack exhaustion can/is caused by recursion so I agree. Thanks for confirming.

8

This problem with delay node I reported in beta 2 still seems not to be working correctly. 🎉 Node-RED 3.1.0-beta.2 released - #45 by Colin

With this flow click the timestamp inject a few times to put some messages in the queue, then click flush to release them one at a time, which does work. However the number in the queue does not go down and after all of them have been released it then proceeds to release empty messages by itself each time the delay runs down.

[{"id":"b219a79eb50cc3ef","type":"delay","z":"43c7680367acf21b","name":"Queue","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"10","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":310,"y":940,"wires":[["c9e8b552e8c90995"]]},{"id":"c9e8b552e8c90995","type":"debug","z":"43c7680367acf21b","name":"debug 96","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":480,"y":940,"wires":[]},{"id":"7a0a1660829ec91f","type":"inject","z":"43c7680367acf21b","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":140,"y":900,"wires":[["b219a79eb50cc3ef"]]},{"id":"d10c601ae39443d3","type":"inject","z":"43c7680367acf21b","name":"Flush","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":110,"y":1020,"wires":[["66b752c1530c4806"]]},{"id":"66b752c1530c4806","type":"function","z":"43c7680367acf21b","name":"Flush","func":"return {flush: 1}","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":250,"y":1020,"wires":[["b219a79eb50cc3ef"]]}]
9

@Colin can you raise an issue with details so it doesn't get missed?

10

Done Delay node Flush when in rate limit mode leaving empty messages in the queue (3.1.0-beta.3 and 2) · Issue #4202 · node-red/node-red · GitHub

11

Thank you for all your work, node-red 2.2.2 allowed us to install data monitoring systems in power plants, wastewater treatment plants, and desalinization plants both in Brazil and the USA.

Our concern is that if we upgrade node.js 14.17.4 to version 16.x and node-red from 2.2.2 to version 3.x will it break our existing code? These systems are live and are running and they are providing compliance to our customers both in North and South America.

Asking this question in another way - is version 16.x and 3.x reverse compatible to version 14.17.4 and version 2.2.2?

Thank you @knolleary or anyone else for any information you can provide,

Kind regards,
JayDL

12

Not sure that any issues were reported in the forum for people moving Node-RED from v2 to v3? I don't remember any.

Moving from node.js v14 to v16 is seamless though you would probably be better off going to v18 which is now also an LTS version. That would let you put off a further node.js upgrade for longer.

One wrinkle however is that, when using node.js, some compiled libraries used in various modules should be recompiled when moving between major versions. Several Node-RED dependencies such as the serial node generally require this. Thankfully it is easy to do though it can be a bit slow on some single-board computers. To do this, all you need is something like this:

cd ~/.node-red
npm rebuild

Of course, doing major version upgrades for any production service, it is always recommended to have test system(s) to do a trial upgrade on before upgrading live.

1 Like
13

Obviously you must try it in a non-production system first. But presumably you have staging systems set up to do that anyway, for any system or flow updates.

Also I presume you have backups so you can quickly restore a system to a working state if it fails for any reason.

1 Like
14

While it should work, there are never any guarantees. You really have to test your specific configuration offline if you want any real assurances.

Never assume it's going to work. Always test offline first.