Debug node - on/off causing deploy button to get triggered

Core Development Feature Requests
1

We might use & think about the behavior of the debug node differently - alright, but for me - I have all my debug nodes off by default, and I just turn them on when I need it for some (debug) reason

Not a big issue, but it has annoyed me since very long, every time you turn debug on or off, the deploy button gets activated. Yeah, you might consider this a change of the flow and therefore...but for me, the way I use it, it is just irritating. In earlier NR versions I do remember this did not activate the deploy button

Obviously, I also see the need to configure the debug node according to your needs but would it not be better to have a checkbox for that in the configuration dialog? The button for turning on/off would then just become a button for that specific purpose, turning debug on/off in the current view, a browser refresh would restore it's configuration

2 Likes
2

Hi - yes this a change we made a long time ago. After much debate (in the old Google group) it was decided that changing the state of debug was a "material change" that should trigger the deploy flag. That way the user is fully aware they have changed something.

3

Hi Dave (@dceejay),

I'm pretty sure that a lot of brains were involved in that debate, a long time before I became familiar with Node-Red. However last week there was a related discussion, where @nlecaude posted following request:

What I'd really like to see in the future is the ability to add a "watchpoint" to a wire in between nodes to allow temporary debugging. What I dislike about debug nodes is they clutter the workspace a lot..

Sometimes I also would like to have a temporary watchpoint, without having to deploy my flow. But from your explanation above, I understand that it was a well thought-out decision to remove such functionality from Node-Red. Correct? If so, it could be a nice node-red-contrib-watchpoint. Would appreciate if you could share your experience about such functionality (e.g. pitfalls, ...).

Thanks !!
Bart

4

Hi, currently wires are not an entity that can have properties, so they cannot have things attached to them. To do this would require changing the flow file format, which would of course be a fundamental change, so it is not something we would undertake lightly.

Of course enhancements to debug would be great, some that are possibly closer are better/more filter options, and breakpoints.

I guess its is also a question of "coding" style. I tend to delete debug nodes once they have server their purpose, in the hope that once working it will stay working, so clutter it not a big issue for me.

5

Hi Dave (@dceejay),

Ah, perhaps I misunderstood the post of Nathanaël. I didn't mean a watchpoint like we know it in a debugger session, because that would indeed be lot's of work involved. I interpreted this as 'something' that you can drop in the flow to watch at the messages of a wire (by displaying them in the debug panel), but without having to deploy something... And of course 'it' would be lost after a deploy.

Is something like that possible? I assume 'yes' since you say that the debug node behaved like that in the past? Or not?
Bart

6

No that is not possible and never has been. What you describe is not the behaviour Dave was referring to. You cannot change anything in the runtime, such as adding a node, without a deploy.

The change in behaviour Dave was referring to was simply whether toggling the active state of a deployed debug node should cause the editor to enable the deploy button or not.

There has never been the ability to drop a node in and have it do anything in the runtime without a Deploy.

7

Ok now it becomes clear howed it work in the early days. Then indeed I can stop dreaming about a temporary debug point ... Thanks both for the clarification !!

8

You could use a function:
brakpoint

[{"id":"534ca0f8.068e7","type":"function","z":"895bbff8.0e6c4","name":"","func":"var warn = typeof flow.get('warn') !== \"undefined\" ? flow.get('warn') : false;\nvar breakpoint = typeof flow.get('breakpoint') !== \"undefined\" ? flow.get('breakpoint') : false;\n\nswitch (msg.topic) {\n    case \"warn\":\n        warn = !warn;\n        flow.set('warn', warn);\n        break;\n    case \"breakpoint\":\n        breakpoint = !breakpoint;\n        flow.set('breakpoint', breakpoint);\n        break;\n    default:\n        if (warn) node.warn(msg.payload);\n        if (breakpoint) node.send(msg);\n}\n\nnode.status({\n            fill: warn || breakpoint ? 'yellow' : 'grey',\n            shape: 'dot',\n            text: 'warn: '+warn+' - breakpoint: '+breakpoint\n        });","outputs":1,"noerr":0,"x":370,"y":2920,"wires":[["2192293.2657fd6"]]},{"id":"cdb18f28.7087a","type":"inject","z":"895bbff8.0e6c4","name":"","topic":"","payload":"show me","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":160,"y":2920,"wires":[["534ca0f8.068e7"]]},{"id":"3fdcdb41.3cf5a4","type":"inject","z":"895bbff8.0e6c4","name":"","topic":"warn","payload":"toggle","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":170,"y":2880,"wires":[["534ca0f8.068e7"]]},{"id":"10c57fbc.38b4","type":"inject","z":"895bbff8.0e6c4","name":"","topic":"breakpoint","payload":"toggle","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":180,"y":2840,"wires":[["534ca0f8.068e7"]]},{"id":"2192293.2657fd6","type":"debug","z":"895bbff8.0e6c4","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","x":550,"y":2920,"wires":[]}]