In order to manage easily debugging sessions it would be great if we could be able to enable/disable all debug nodes of a flow/subflow/group.
I’m aware that we can filter debug nodes of the actual flow and/or select debug nodes to display but it’s really a long process to add selectively specific groups of a several flows and it’s only filtering so all debug nodes are always working in background.
If we could directly enable/show and disable/hide all debug nodes belonging to a flow/subflow/group. It could permit to selectively activate debugging for several flow/subflow/group with a clear view where the debug nodes are active or not and avoid nodes debug visual pollution on other flow/subflow/group display.
I could understand the actual logic to regroup all the debug informations and related filters in the debug window but intuitively we are looking related debug selection in flow/subflow/group context menus.
In case it’s a no go to manipulate debug nodes outside the debug window, is it possible at least to add group selection in actual filters ?
then all the debug nodes are shown in the Info tab of the right hand column, grouped by flow.
Each one has a "Trigger Action" button which toggles whether the node is active and a "Disable" button to disable the node entirely.
Amazing ! Who will think to search for “debug” in the info panel to be able to select debug nodes ? Not me at least
It’s a nice shortcut but that still require to deactivate debug nodes one by one and at each click you come back to the beginning of the unfolded list so I need to scroll and find back the flow/subflow/group for each debug node.
I wish I could activate/deactivate debug nodes for a whole flow/subflow/group with one click and not a scroll/search/click for each node.
In fact you need to scroll if you have fold flow/subflow/group because after click everything is unfold.
And folding is a way to eliminate whole flow/subflow/group.
There are actions available in the actions list (crtl-shift-p or context menu) to (de-)activate all and all flow debug nodes. You can also bind keyboard shortcuts to those actions.
Unfortunately there is no such action for groups, but it should work inside a subflow template.
also you can use type:debug to make it a type search instead of a "text" search. Works with any node type, i.e., type:type would find all nodes with the type: type!
I understand now why there is so many available keyboard shortcuts
Firstly I’ve struggled to assign a valid key shortcut that was not used by node-red/browser/desktop and then I’ve tested it and unfortunately it works only with flows but not with subflows and groups.
It require two keyboard shortcuts and if subflows/groups could me managed by the same option, that could be the feature I’m looking for. So actually it is still a feature request.
type:debug lists all debug nodes of all flows.
I need to use flow:current type:debug to be able to select all nodes of the current flow.
This way are more precise way that searching for debug but finally it also requires to activate/deactivate all debug nodes one by one (with the reset of folding groups at each time that bring the scroll in play).
You can also use one or more "reusable" debug nodes, which receive messages from multiple nodes via link-out/link-in.
This way you can enable/disable with a single click, but the downside is that clicking the message on the debug pane does not highlight the sender
This kind of feels like a feature I'd already indicated could go into my experimental inline debug node. In that, I'd suggested that it might be useful to respond to something like a msg._debug property in received messages that, if set to false would not output the debug. That would continue through to any nodes in the flow as long as the msg wasn't reset somewhere.
Another option might be to use a config node with it. The config node could have a switch so that all inline debug's with the same config could be turned on/off together but you could still have multiple configurations.
I've not done anything with that experiment because there didn't seem that much interest.
I really like your debug approach as most of serious debug session consists mainly to follow messages and their related values through the flow and so either add step by step debug nodes to follow and discover where the problem is or put many debug nodes once with adapted name to follow the logic. If you don’t deactivate systematically all your debug nodes, the debug window can be filled quickly and you have to selectively deactivate nodes or manage debug filters to see what you need. So that became really a mess especially if you need to debug alternatively different groups in the same flow.
A msg._debug by node could permit to print needed objects or attributes with their relevant node name avoiding to add debug nodes with related nodes names and avoiding in the same time visual flow pollution. In fact it could be simply a debug field that can be filled accurately as actual debug node (out property) and a check box to activate it by default or not.
That bring even the possibility to use specific value for msg._debug to start/stop debugging of a flow on one or several conditions with a simple change node that can simply be activated/deactivated on demand.
A debug system integrated in the flow is really a good option as it can be simply activated/deactivated globally or by flow (stop to treat _debug attributes). In fact I’m surprised that is not the case actually because your idea marry fully the node-red flow philosophy.
A such debug system could bring another great benefit for palette too as it could be possible to let debug informations in palette flow and so be able to activate it on demand to provide debug information for palette upstream developers. I don’t think this is possible actually with current debug implementation.
I would really enjoy such feature but actually my main point is still related to subflows and especially groups that I use a lot. With the group contextual menu it is possible to activate/deactivate all nodes and I would simply like to do accurately the same to activate/deactivate all debug nodes.
I have just pushed the current experimental code to GitHub.
It isn't published yet but you can install it manually. It should work in its current form though the things I posed in my last post are not yet live. Currently, you can turn it on/off manually in the node settings. I'll try to find some time to work on it.
[1]: all the client code does is run JS code in the browser triggered from the server. The results of the client code execution are sent back to the server.
