Complete node doesn't check for recursion

Core Development
1

Hi There,

as part of my Erlang-RED thingy, I'm creating a test suite of flows for testing the functionality of the core nodes.

I've just come to the complete node and discovered that it's fairly simple to create an endless loop, this flow:

Screenshot 2025-04-19 at 19.58.45
Screenshot 2025-04-19 at 19.58.45849Ă—361 11.7 KB

[{"id":"5ae6a7d5d44da483","type":"inject","z":"10642cf9052e8079","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":395,"y":825,"wires":[["036933e4ccc328e9"]]},{"id":"70cab6b8dd684978","type":"complete","z":"10642cf9052e8079","name":"","scope":["5ae6a7d5d44da483","e763535a1e29636d","036933e4ccc328e9"],"uncaught":false,"x":646,"y":658,"wires":[["e763535a1e29636d"]]},{"id":"e763535a1e29636d","type":"debug","z":"10642cf9052e8079","name":"debug 394","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1003,"y":638,"wires":[]},{"id":"036933e4ccc328e9","type":"debug","z":"10642cf9052e8079","name":"debug 395","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":845,"y":840,"wires":[]}]

basically the complete node listens to the debug connected to itself and well ... yes I had to restart node red after pressing the button on the inject node. Of course, complete also listens to the other two nodes, else it would receive any message.

I used 4.0.5 for that.

I guess one way to prevent this would be to check what nodes are connected to the complete and don't show them in the list. However what about second degree nodes (i.e. nodes connected to the nodes connected to the complete). I can understand this is a non-trivial thing to prevent but on the other hand message do have msgid and the complete node could keep a list of them ....

EDIT: msgId won't work since complete should (in this flow) receive the same msgId three times - once each from all three nodes. But how should it know that.

1 Like
2

You are correct - there is no simple way to stop infinite loops but yes we could detect the first order loops as you mention (by checking for directly connected nodes) . That would certainly help reduce the number of situations as I guess a lot are exactly as you have it - debug connected to the complete node to see what is going on.

3

I just fixed this[1] by modifying the message and marking it with a list of complete node ids. I.e., similar to what _linked_sources does in that each link call adds itself to that list.

I added a _complete_list to the message the complete node sends out. That works fine.

[1] = in the erlang version --> this code.

4

Yeah. It’s a bit of an anti-pattern for flow based programming that nodes shouldn’t need to know where messages are coming from. And I don’t think we would want start adding that for every message in the core.

5

Raised PR for simple (one level) fix here - Fix complete node to not feedback immediately connected nodes by dceejay · Pull Request #5114 · node-red/node-red · GitHub