Making branch node execution order obvious and intuitive

[ResoTek Inc]

Branch node execution order is neither intuitive nor immediately apparent by looking at a flow. For instance, the debug nodes do not print in the expected order in my Node-RED v0.14.5 debug tab, complicating the debug process. The debug cascade flow below is illustrative, as the debug tab messages are not shown in chronological order (the inject node prints last). This makes following a sequence events on the debug tab quite difficult.

[{"id":"58798058.a0a8b","type":"function","z":"ea54b7f0.41f8c","name":"Add1","func":"msg.payload = msg.payload + 1;\nreturn msg;","outputs":1,"noerr":0,"x":350,"y":240,"wires":[["3ac686f5.5dbc12","c16e690a.6fbe28"]]},{"id":"678e7d4b.f53004","type":"inject","z":"ea54b7f0.41f8c","name":"","topic":"","payload":"0","payloadType":"num","repeat":"","crontab":"","once":false,"x":170,"y":160,"wires":[["58798058.a0a8b","712289f2.2b07b8"]]},{"id":"3ac686f5.5dbc12","type":"debug","z":"ea54b7f0.41f8c","name":"1","active":true,"console":"false","complete":"payload","x":510,"y":240,"wires":[]},{"id":"712289f2.2b07b8","type":"debug","z":"ea54b7f0.41f8c","name":"0","active":true,"console":"false","complete":"payload","x":510,"y":160,"wires":[]},{"id":"c16e690a.6fbe28","type":"function","z":"ea54b7f0.41f8c","name":"Add1","func":"msg.payload = msg.payload + 1;\nreturn msg;","outputs":1,"noerr":0,"x":350,"y":320,"wires":[["5add8147.2e2488","a8364970.5524d8"]]},{"id":"5add8147.2e2488","type":"debug","z":"ea54b7f0.41f8c","name":"2","active":true,"console":"false","complete":"payload","x":510,"y":320,"wires":[]},{"id":"a8364970.5524d8","type":"function","z":"ea54b7f0.41f8c","name":"Add1","func":"msg.payload = msg.payload + 1;\nreturn msg;","outputs":1,"noerr":0,"x":350,"y":400,"wires":[["8526ee25.f5388"]]},{"id":"8526ee25.f5388","type":"debug","z":"ea54b7f0.41f8c","name":"3","active":true,"console":"false","complete":"payload","x":510,"y":400,"wires":[]},{"id":"9cb2f66e.4b8f08","type":"comment","z":"ea54b7f0.41f8c","name":"Cascade.Note order of debug output","info":"","x":260,"y":80,"wires":[]}]

NOTE: If the above flow does print in chronological order in your case, try deleting the first debug node, then deploying, then add the node back (or just rewire it) and then redeploy.

Apparently the order in which branch nodes were wired to their preceding nodes determines the execution order. I think it would be better if instead branch execution order were immediately apparent simply by viewing a flow.

Has branch node execution order based on y then x node position been considered? At least then the order would be predictably top to bottom, left to right, and easily controllable by moving the node's y or x position. Currently I know of no way to determine which branch will execute first simply by looking at the flow. It is similarly inconvenient to have to rewire branches to change the branch execution order. Dragging nodes to a different xy location seems to be the obvious solution, as it would not require presenting any new object properties to the end-user. I won't get into the link-in node or flow execution order at this stage, but that could also be made predictable by looking at the flows rather than remembering wiring order.

To illustrate, can any of you predict the execution order of the flow below by viewing it in Node-RED? Unless you reconnect the flow wires yourself and remember the wiring order, I expect you cannot.

[{"id":"dd078663.c1d358","type":"function","z":"ea54b7f0.41f8c","name":"One","func":"msg.payload = 1;\nreturn msg;","outputs":1,"noerr":0,"x":870,"y":200,"wires":[["a7d70959.0466"]]},{"id":"8b596718.b8177","type":"inject","z":"ea54b7f0.41f8c","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"x":680,"y":200,"wires":[["dd078663.c1d358","8043a585.6e0968","7bb8b43f.0cae2c","b1c8a324.4c79"]]},{"id":"7bb8b43f.0cae2c","type":"function","z":"ea54b7f0.41f8c","name":"Two","func":"msg.payload = 2;\nreturn msg;","outputs":1,"noerr":0,"x":910,"y":140,"wires":[["a7d70959.0466"]]},{"id":"8043a585.6e0968","type":"function","z":"ea54b7f0.41f8c","name":"Three","func":"msg.payload = 3;\nreturn msg;","outputs":1,"noerr":0,"x":950,"y":260,"wires":[["a7d70959.0466"]]},{"id":"e68dcfdf.6235f8","type":"comment","z":"ea54b7f0.41f8c","name":"Note order of Race Condition","info":"Function names equate to order in \nwhich function nodes were pasted into the flow.\nEvent order appears to be the order in which\nthe function nodes were wired to \nthe inject node output","x":880,"y":40,"wires":[]},{"id":"a7d70959.0466","type":"debug","z":"ea54b7f0.41f8c","name":"","active":true,"console":"false","complete":"false","x":1130,"y":200,"wires":[]},{"id":"b1c8a324.4c79","type":"function","z":"ea54b7f0.41f8c","name":"Four","func":"msg.payload = 4;\nreturn msg;","outputs":1,"noerr":0,"x":970,"y":80,"wires":[["a7d70959.0466"]]}]

A top-down execution order would also be useful for resolving (avoiding?) race conditions without complicating the flow. They are not truly race conditions if you remember the wiring order, but if you don't remember, it seems like a race condition. An example use case for avoiding branch node race conditions would be the ability to send out multiple consecutive messages by using different nodes. Currently, sending out consecutive messages requires sending out a payload.msg array, but that must be done from a single function node, and cannot be merged from other nodes without creating an unpredictable message sequence order. Solving this would make it quite easy to control the order of a message sequence originating from non-blocking branch nodes.

Previously I posted this in the "Request: Trace node" thread, but I think it deserves its own thread.

TL;DR: Let's consider implementing top-to-bottom branch node execution order instead of the current temporal "wiring order" implementation.

[Nicholas O'Leary]

Hi,

the order of node execution is an interesting topic.

One of the principles of flow based programming is that once a flow branches, they are independent and no assumptions should be made about execution order. If you want to ensure one node executes before another, you should construct your flow so they appear in the same branch.

We have an open issue (https://github.com/node-red/node-red/issues/833) on how messages pass between nodes that has a material affect on the order branches. Currently, a branch will get processed, node to node, until an async action occurs (such as an network IO request). At this point the event stack will unwind and the next event processed, which could well be a message on a different branch. How two branches are processed will then depend on what individual nodes are in them and which contain async actions. If none of the nodes contain async actions, you affectively get depth-first execution.

It is far better (and predictable) for the passing of messages between each node to be an async action. That means when a flow branches, the two branches will be processed in 'parallel' (in as much as a single-threaded runtime does anything in parallel) - akin to breadth-first execution. Some quick testing showed some small performance improvements to be had by doing this.

All of that said, there is the question of what order a node queues up the delivery events to subsequent nodes. Ignoring the broader question of the order entire branches are executed in, I can see there are benefits to making that order more obvious. Specifically your example where you add Debug nodes along a flow, it would be reasonable to see those debug messages appear in the correct order. So I'm happy to explore this idea further.

Ultimately, as with issue 833, even though we make no statements on the order of message processing, _any_ change to the order will inevitably break someone who depends on the existing order. That means this isn't something we can rush into doing and must be done with care.

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

[ResoTek Inc]

Nick,

Thank you for your thoughtful response. Although a change in branch node execution order may break some flows, it could be argued that some flows are already broken if the debug nodes print out of chronological sequence. I'm glad this has your attention, but I understand that a solution should not be rushed. Please let me know if you create a separate issue for this so that I may subscribe to it. Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

[Dave C-J]

... I think you mean they DO print out in chronological order... but that order is not what you are "expecting" it to be... and so it looks broken.

[ResoTek Inc]

Thank you for the clarification.

[Mike Bell]

Just out of curiosity, if several node outputs are wired to a single debug node, is it safe to assume that the print out will be in the order that the messages are received? If so, is this a reasonable way to see how reproducible the timing is in a branched flow?

[Dave C-J]

yes - as node.js is (mostly) single threaded then once a message arrives a the input of a node it can't be "overtaken" within the node - so order of print is order of arrival.

[ResoTek Inc]

I followed Mike's lead and modified my Cascade flow to send all outputs to the same debug node.

[{"id":"9cb2f66e.4b8f08","type":"comment","z":"ea54b7f0.41f8c","name":"Cascade.Note order of debug output","info":"","x":260,"y":80,"wires":[]},{"id":"c7e97f45.92989","type":"function","z":"ea54b7f0.41f8c","name":"Add1","func":"msg.payload = msg.payload + 1;\nreturn msg;","outputs":1,"noerr":0,"x":290,"y":240,"wires":[["c5a2568f.38988","717cf3fd.abf714"]]},{"id":"3584168.3c6ad6a","type":"inject","z":"ea54b7f0.41f8c","name":"","topic":"","payload":"0","payloadType":"num","repeat":"","crontab":"","once":false,"x":110,"y":160,"wires":[["c7e97f45.92989","717cf3fd.abf714"]]},{"id":"c5a2568f.38988","type":"function","z":"ea54b7f0.41f8c","name":"Add1","func":"msg.payload = msg.payload + 1;\nreturn msg;","outputs":1,"noerr":0,"x":290,"y":320,"wires":[["ac4e1df.42dad6","717cf3fd.abf714"]]},{"id":"ac4e1df.42dad6","type":"function","z":"ea54b7f0.41f8c","name":"Add1","func":"msg.payload = msg.payload + 1;\nreturn msg;","outputs":1,"noerr":0,"x":290,"y":400,"wires":[["717cf3fd.abf714"]]},{"id":"717cf3fd.abf714","type":"debug","z":"ea54b7f0.41f8c","name":"","active":true,"console":"false","complete":"false","x":484.59999084472656,"y":187.4166717529297,"wires":[]}]

I expected that the inject node value would print first or second on the debug tab (Breadth first order of execution of nodes). However, it still printed after the third cascaded function node, implying depth-first ordering. What am I missing here?

[Dave C-J]

Hi,

as per your original post.... The order of execution of "branches" is not easily deterministic... it is indeed as you pointed out - more determined by the order in which you place and wire up the nodes on the page.

Personally I prefer multiple single debug tabs as at least then hovering over the message in the debug panel will highlight which debug node it came from which if then wired to one place will show what the output at that point was.

[ResoTek Inc]

Before today I had always used debug nodes with single input wires. It would be nice if we could also associate debug nodes to their debug messages in the node-to-message direction and somehow highlight or scroll to the debug node's last output message in the debug panel, much like double clicking on a message changes to the relevant flow and highlights the node, as you stated. A node-to-message association should reduce the current message-to-node trial and error when looking for a specific debug node output. If the order of node execution were more predictable, that would be less needed.

[Rial Williams]

I'm resurrecting this thread as I have just run into a sequencing issue with a flow I've been building/debugging.  Here's the pseudo-flow: MQTT Input - Function - MySQL Query - Function - Delay - MQTT Output.  At each node output (except the last one) I branched to a debug node (I'm watching latency).  When I run the flow and look at the outputs from the debug nodes, they are not in proper chronological order (as has been mentioned elsewhere in this thread).  My flow is a straight no-branch thing and (after pulling most of what's left of my hair out) it works as expected so I know my nodes are executing in the proper order.  When I wrote the flow, I consciously placed the (non-debug) nodes on the flow one at a time, left to right wiring them up as I went.  I deployed and tested the flow successfully.  I then went back and wired the debug nodes in left to right and deployed.  Now when the flow runs, all is well with the process, but the debug node data prints out in a different order.  There are 5 debug nodes and I named them left to right 1 through 5.  The order they show up in the debug window is (top to bottom) 2,1,4,3,5...consistently.  Yes, I can sort them out, but it's easy to go off on a troubleshooting tangent if one is not paying close attention (ADHD and all that).  I can understand the difficulty of getting the proper execution sequence once branches to other active nodes is concerned, but simple debug nodes off a serial flow should surely be in order.  BTW, I'm using V0.15.2 NodeRED.  Flow is attached.

[Colin Law]

On 17 February 2017 at 15:13, Rial Williams <rial.w...@gmail.com> wrote:
> I'm resurrecting this thread as I have just run into a sequencing issue with
> a flow I've been building/debugging. Here's the pseudo-flow: MQTT Input -
> Function - MySQL Query - Function - Delay - MQTT Output. At each node
> output (except the last one) I branched to a debug node (I'm watching
> latency). When I run the flow and look at the outputs from the debug nodes,
> they are not in proper chronological order (as has been mentioned elsewhere
> in this thread). My flow is a straight no-branch thing

It *has* got branches. The debug nodes are on branches.

Colin

> and (after pulling
> most of what's left of my hair out) it works as expected so I know my nodes
> are executing in the proper order. When I wrote the flow, I consciously
> placed the (non-debug) nodes on the flow one at a time, left to right wiring
> them up as I went. I deployed and tested the flow successfully. I then
> went back and wired the debug nodes in left to right and deployed. Now when
> the flow runs, all is well with the process, but the debug node data prints
> out in a different order. There are 5 debug nodes and I named them left to
> right 1 through 5. The order they show up in the debug window is (top to
> bottom) 2,1,4,3,5...consistently. Yes, I can sort them out, but it's easy
> to go off on a troubleshooting tangent if one is not paying close attention
> (ADHD and all that). I can understand the difficulty of getting the proper
> execution sequence once branches to other active nodes is concerned, but
> simple debug nodes off a serial flow should surely be in order. BTW, I'm
> using V0.15.2 NodeRED. Flow is attached.
>
>>

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.

> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/node-red/219425a0-317e-4b37-9c3b-d88b496fabb2%40googlegroups.com.

[Rial Williams]

Yes, dead-end, identical debug branches inserted into the flow, left to right.  What's your point?

[Colin Law]

On 18 February 2017 at 02:10, Rial Williams <rial.w...@gmail.com> wrote:
> Yes, dead-end, identical debug branches inserted into the flow, left to
> right. What's your point?

To quote from Nick's original reply

> One of the principles of flow based programming is that once a flow branches, they are independent and no assumptions should be made about execution order. If you want to ensure one node executes before another, you should construct your flow so they appear in the same branch.
> We have an open issue (https://github.com/node-red/node-red/issues/833) on how messages pass between nodes that has a material affect on the order branches. Currently, a branch will get processed, node to node, until an async action occurs (such as an network IO request). At this point the event stack will unwind and the next event processed, which could well be a message on a different branch. How two branches are processed will then depend on what individual nodes are in them and which contain async actions. If none of the nodes contain async actions, you affectively get depth-first execution.

As I understand it the messages branched off into the debug nodes sit
waiting to be actioned while the main message proceeds down its
branch. Once that one completes then the debug nodes are all sitting
with messages in their input queues but it is not (in any obvious way)
determinable which debug node will get actioned first. The outputs
from the debug nodes *are* in chronological order, in that the node
that gets serviced first will print its message first, but the order
they get serviced is not the one you expect.

If you read the rest of Nick's original reply there is more information on this.

Colin

>
> On Friday, February 17, 2017 at 10:32:36 AM UTC-5, Colin Law wrote:
>>
>>
>> It *has* got branches. The debug nodes are on branches.
>>
>> Colin
>>

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/62494b08-c38d-42b5-a724-b71ec048d1fe%40googlegroups.com.

[Rial Williams]

There must be a way to determine in which order nodes will execute.  An interesting thing with my code (posted earlier in this thread) is that when I run it from work, using a local LAN NodeRED installation on Ubuntu, the debug responses arrive in the "wrong", but consistent order.  When I took my flow home and ran it against my NodeRED server there (same Ubuntu OS and same NodeRED version 0.15.2), the debug outputs showed up in the "correct" order consistently.  The only thing I didn't check was if NodeRED is the same version at home as here at work.  I'm a PLC programmer and as such, am obsessed with execution order.  I really want to like NodeRED, but I can't trust it as far as this execution order stuff goes.

[Mark Setrem]

We appear to going round in circles! As Nick has said you
can't be certain of the order that branches are executed and as Colin pointed out if you have a debug node connected mid-flow it is by its very nature a branch.

There is no "correct" order for a branched flow to execute. This might be a bit of a cerebral-retread for a PLC developer but that's a Principle of flow based programming

[ResoTek Inc]

Although branch execution order is not sequential, the intent of users is clearly for the Debug node to print on the Debug window as soon as the sending node sends out the message, so that the debug console print order matches their linear flow. The conversation tends to boil down to philosophical differences that, although they do represent the asynchronous nature of node, they do not solve the problem at hand. Users clearly intend that linear flows print debug messages chronologically, and they do not intend for a Debug node to be an asynchronous branch. Stating that it is a branch explains the problem, yet it does not provide a solution to synchronously monitoring messages.

Therefore, I propose this solution: how about changing node input and output connector behaviour so that any node connector port can be tagged to print to the log console so that we can monitor messages synchronously? Graphically, monitored input or output connectors could be displayed as a green right-pointing isosceles triangles rather than as grey squares. The user could toggle the connector from logging to non-logging by double-clicking on the respective connector. Connector dragging behaviour with respect to wiring would continue as before.

With the above approach, rather than adding debug nodes to gain insight into a flow, the user could simply double-click on inputs or outputs to be logged to the debug console. After all, in many cases, that's often the reason they're placing debug nodes into the flow, isn't it?

If you want to get fancy, a menu option could be added to turn off all logging, or to enable/disable connector logging by colour. For example, display only the green monitored connectors, or display only the blue monitored connectors. Perhaps a right-click could be used on the connector to select which logging it belongs to.

[Rial Williams]

Reso Tek Inc has a good idea, but how about this...Just change the debug mode to have an input AND an output. The node would just pass whatever shows up at its input along to its output while dumping the msg object to the debug window. Then, the programmer could just drop it in a serial flow and know that the debug trace will be in proper order. By the way, us PLC programmers have a language we call CFC that looks a lot like NodeRED, but we have the ability to specify the execution order. This helps us to close the barn door BEFORE the horse gets out.

[Colin Law]

I think the idea of making the debug node 'pass through' is an excellent idea, if it is not technically difficult to achieve.

If necessary I think one can easily achieve something similar, however, by using a function node containing something like:

node.warn("payload = " + msg.payload);

return msg;

Not as convenient or flexible as the debug node but probably adequate when one is trying to solve those occasional problems where the order of the debug o/p is an issue.

Colin

On 22 February 2017 at 02:15, Rial Williams <rial.w...@gmail.com> wrote:

Reso Tek Inc has a good idea, but how about this...Just change the debug mode to have an input AND an output.  The node would just pass whatever shows up at its input along to its output while dumping the msg object to the debug window.  Then, the programmer could just drop it in a serial flow and know that the debug trace will be in proper order.  By the way, us PLC programmers have a language we call CFC that looks a lot like NodeRED, but we have the ability to specify the execution order.  This helps us to close the barn door BEFORE the horse gets out.

--
http://nodered.org

Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send an email to node...@googlegroups.com.

Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/a76f7693-6ca1-4366-92fb-fa8cae062e0a%40googlegroups.com.

[Rial Williams]

Colin, I just tried your idea and it effectively will work as an inline debug node.  It's a little clunky as I can't turn it on and off like I can a debug node, but it might help me get out of trouble today.  Thanks for the idea!

On Wednesday, February 22, 2017 at 2:40:40 AM UTC-5, Colin Law wrote:

I think the idea of making the debug node 'pass through' is an excellent idea, if it is not technically difficult to achieve.

If necessary I think one can easily achieve something similar, however, by using a function node containing something like:

node.warn("payload = " + msg.payload);

return msg;

Not as convenient or flexible as the debug node but probably adequate when one is trying to solve those occasional problems where the order of the debug o/p is an issue.

Colin

On 22 February 2017 at 02:15, Rial Williams <rial.w...@gmail.com> wrote:

Reso Tek Inc has a good idea, but how about this...Just change the debug mode to have an input AND an output.  The node would just pass whatever shows up at its input along to its output while dumping the msg object to the debug window.  Then, the programmer could just drop it in a serial flow and know that the debug trace will be in proper order.  By the way, us PLC programmers have a language we call CFC that looks a lot like NodeRED, but we have the ability to specify the execution order.  This helps us to close the barn door BEFORE the horse gets out.

--
http://nodered.org

Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

[Colin Law]

To turn it off temporarily stick a # on the front of node.warn and redeploy (just that node).

Obviously you can put some text in the displayed string so you know which node the message comes from.

Colin

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.

Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/1d375769-eeb6-4e30-aa0b-e4a2bb7ee80e%40googlegroups.com.

[steve rickus]

It seems to me that the purpose of most (non-endpoint) nodes is to take an input msg, modify its contents, and pass it downstream. To test a node's logic, the flow creator needs to insert debug nodes before and after each node, usually with different input data injected. In fact, some of my flows have 4-6 other nodes linked to some logic node just to make sure it's working the way I want, which IS rather clunky, apart from the log timing issues.

It occurs to me that the NR team has created two powerful ways for visualizing JSON objects -- the interactive console debugger, and the flow comparator. If I had my wish, I could select ANY node in my flow and pop up an interactive comparison window of the incoming vs. outgoing msg object that was last processed. Alternately, if it's too much overhead to keep the msg history, open an interactive comparison window before triggering the input msg. Either way, it could eliminate most of the debug nodes that I'm using now, and that just take up space from the main flows.

In the past, Nick and Dave have been reluctant to use the flow editor as a monitoring tool, so they probably would have other thoughts. And finding a way to select which nodes to monitor could be tricky from a UI standpoint. But I just wanted to put this out there for comments...

--

Steve

[Colin Law]

On 22 February 2017 at 14:08, Colin Law <cla...@gmail.com> wrote:

To turn it off temporarily stick a # on the front of node.warn and redeploy (just that node).

Oops wrong language (Ruby) // will probably work better :)

It took me ages to get used to putting all those ; on the end of lines and parentheses round function parameters and particularly 'if' conditions.

[ResoTek Inc]

However, having to break and redraw wires for a pass-through debug node certainly slows things down. In general, Debug nodes take up a lot of room, and in tight flows, we must rearrange the nodes to make room for the Debug nodes (or pass-through nodes), further slowing flow debugging.

The recent control-click menu added to Node-RED to speed flow entry gives me hope that node-RED developers may be interested in speeding up the debug process too. A simple double-click on a connector port could toggle port/connector msg logging of msg content and port name (IN or OUT[n] port). If Dave and Nick are still subscribed to this thread, it would be nice to hear whether they think this is viable. Should we create a github feature request issue for this?

[AutoDoc Williams]

I like your idea better than my inline debug node.  I'm just thinking that it might be easier for the developers to tweak the debug node they have now and maybe incorporate your idea in the long term.

[Simon H]

just to come back to making a flow execution order deterministic where required;

for parts of my flows where order of execution for multiple wires out of a single node is important, I create a function node with multiple outputs, and with content:

node.send([msg, null, null];

node.send([null, msg, null];

node.send([null, null, msg];

Of course, any downstream node which goes async on you will break this (e.g. file reader bit me the other day).... so you still have to have a fair understanding of what does what.

s