🎉 Node-RED 3.0.0-beta.3 released

I'm hitting a bug in V3 (all betas) where nodes get moved to the current tab on initial load. It's a race condition and doesn't always happen and I don't know yet how to create a repro. Here's a screen shot of how it looks, all the nodes that sit on top of others are really supposed to be in other tabs.

I've been debugging this and this is what I've found:

  • the flow file is correct and many times that I reload the browser everything shows correctly, but about 1 in 3 browser reloads results in the mess above
  • the reason the nodes show up in the wrong tab is that they get assigned activeWorkspace in importNodes node-red/nodes.js at master · node-red/node-red · GitHub
  • this happens because workspace_map[node.z] doesn't exist
  • the reason this doesn't exist is that importNodes gets called from the registery:node-type-added event handler with a list of nodes to reimport: node-red/nodes.js at master · node-red/node-red · GitHub and the list of nodes passed into importNodes only includes the nodes of that type and not any workspace nodes
  • in importNodes the workspace_map only includes workspace nodes that are passed in its argument list, not ones that have been previously imported, e.g. workspace_map is incomplete at the re-import time which the module global workspaces has all the workspaces.

This race condition is pretty fatal in that if one doesn't see the problem and deploys then the wrong placement of the nodes is saved.

3 Likes

What is that node with the rocket icon? Is it only instances of that node that move?

Hi @tve - please do raise an issue with the details you have identified. That will ensure it doesn't get missed.

Thanks!

It's a flexdash-related node. The bug happens when nodes of a given type are reimported when the type gets defined, that's why all the affected nodes are of the same type.

Can you explain that a bit more? The editor loads all of the node definitions before it loads the flow configuration from the runtime. So everything should already be defined and no nodes should be added to the editor "when the type gets defined".

Maybe I'm misunderstanding your meaning here, or there's some specific behaviour of your flexdash nodes that I'm missing?

Repro coming. Has nothing to do with FlexDash. If you follow the links to the code in my explanation above you can see how the node-type-added event handle re-imports nodes when the type gets defined.

That whole code path is related to when the flows are loaded with 'unknown' nodes - but the node type is subsequently added to the runtime. The editor can then update all of the 'unknown' nodes with the real nodes.

That is not a normal code path for when you open the editor. All of the types should be registered and available before the editor loads the flow configuration.

So I'll be interested to see your steps for reproducing this.

Github issue with link to repro: nodes get moved to current tab on flow-edit launch due to race condition · Issue #3699 · node-red/node-red · GitHub

1 Like

I accidentally double-clicked the right button and ended up with this.

This issue is due to the fact, that - when opening the editor dialogs - the keyboard shortcut mapping is not disabled. I'll raise a PR to get this fixed.

1 Like

Is there a constrain with V3 to use an older version of the dashboard? I am at V2.22 and cannot update because I am using an old iPad as main output screen.

No - all nodes should keep working as-is. There are no significant breaking changes (other than dropping support for Node 12).

1 Like

Re: junction nodes. When I'm wiring to/from a junction node I'm finding it quite annoying that the node only expands when the cursor is on the junction dot and not already when it is on the yet-to-appear wiring dot. E.g., I know where the wiring dot will appear and I'd like to move the cursor right there, have it appear, and release the button. As opposed to having to move onto the main junction dot, wait for it to expand and show the two wiring dots, then slightly correct my mouse position so it's on the wiring dot, and then release the button.

You can simply let go on the center dot and it will know from the wire direction which side to attach.

But i agree, it would be nice to have a hidden detection radius

1 Like

Re: text editor. When I re-open a function node the editor remembers the previous text selection. That's probably good, dunno.. However, when I click somewhere else, it's as if I had shift-clicked, i.e. the selection gets extended to where I click. This happens systematically for me when I re-open a function node where I've previously set the cursor, not the first time I open one. Using Vivaldi (latest) or firefox (latest) on Linux.

Thanks for pointing that out! It doesn't work when wiring from a junction node, though, due to confusion with moving the node.

Which editor - ace or Monaco or both?

how can I tell?

Done.

Settings.js -> codeEditor

In short, if you get helpful snippets, syntax errors for undefined variable, a command palette (f1 or right click), function intellisence, parameter help, jsdoc support and can see a mini map on the right - you have Monaco

If you get basic error highlighting (a red Mark in the left-hand column) you have ace (which will probably be dropped in the next version of node-red since Monaco provides a much richer experience)

3 Likes