When there is a lot of debug output, the debug window auto-clears and auto-scrolls. This sometimes makes it very hard to inspect a single object. It would be useful to have a button that allows suspending incoming debug messages.
2 Likes
A debug pause - yes, a sensible suggestion.
1 Like
This is something that is hard to get right.
What is "lot" of debug? So a lot scrolls past, you hit pause. You discover that the debug you're looking for isn't there. You unpause but now even more scrolls through because all the buffered messages first get pushed through. Or do you drop all message when paused? Do you have an configuration options for this choice?
As soon as you have a pause button you have a non-binary'ness: on, off and something else! It's that something else that is hard to get right.
There is always the filter option
But that's kind of limited so you might not be able to filter on what you want.
My experience is that the debug message count limit is a pain - the messages I tend to look for are already gone "off screen" (so to say). Of course a limitless debug panel will soon flood the browser memory. A pause won't help me since when does the message arrive that I'm looking for? Debugging is investigating non-deterministic behaviour of a system.
In fact though, the debug panel isn't an log of debug messages but actually intended as a design-time debug log, i.e. you design your flow, test it using the debug panel, then deploy the flow and that's it. So anything that happens in "production" should be logged somewhere else, not necessarily to the debug panel in a browser.
Reminds me of Nicks words of wisdom "Node-RED isn't a dashboard". I've been the first to ignore this wisdom and sometimes it does catch up on me. But if you take that into consideration, then it makes sense why the debug panel is as it is.
Perhaps a better approach would be some kind of logging service, i.e., being able to send all debugs to elastic-search (or datadog or AWS logging-based-on-elasticsearch) with the flick of a button.
Especially since production systems generally don't use a browser window as logging service 
If you still want a pause button, you could also deactivate those debug nodes that perhaps are generating stuff that you're not interested in. We all do this: start creating a flow, add a debug, fix the problem, create more flow, add more debug, ..... and nowhere do we remove the debugs that are no longer needed.
So perhaps having too much debug noise is a sign for some cleaning up of flows. Obviously most of the debug output isn't of interest, else there would be a lot of reading to do
So I for one am for keeping the debug limit and the debug panel as is, because having too much debug is a sign to refactor flows - and that keeps the flows neat and tidy.
Also there is the option of sending the message to the console. When looking for something that happens occasionally I add some debug nodes sending to the console, then one can look back through the node-red log to see exactly what happened.
the old tail -f node-red.log | grep what_have_i_done trick ...
1 Like
Or the new journalctl -f -u nodered -g "some_diagnostic_text"
Or if looking for messages that happened earlier
journalctl -b 0 -u nodered -g "some_diagnostic_text" --no-pager
I would give the debug nodes names that all start with a unique string and then search on that will find all the output from debug nodes with names starting with that.
The -b 0 means 'since last boot' to save it looking back through the complete journal.
2 Likes
Another alternative is to simply create your own output cache in a context variable. Then you can easily control the size of the cache.
The UIBUILDER uib-cache node does this already and you can use it anywhere.
I'm using flogger for debugging if needed. It writes the debug output to a file. If the debug output occasionally, and you can look as far back as needed.
Yes, I use that too.
I am well aware of filter option.
In fact though, the debug panel isn't an log of debug messages but actually intended as a design-time debug log,
Exactly! I agree in this. And this is exact reason why that log tool need pause.
Perhaps a better approach would be some kind of logging service, i.e., being able to send all debugs to elastic-search (or datadog or AWS logging-based-on-elasticsearch) with the flick of a button.
As you just say. It is not logging service. It is net to design-time debug log. And some odd reason now you try turn things around back to logging service? I am not looking logging service. I am looking better ui to debug things.
If you still want a pause button, you could also deactivate those debug nodes that perhaps are generating stuff that you're not interested in.
You clearly only see your own use case and assume everyone uses Node-RED for the same thing you do. I run over 30 Node-RED instances witch each have > 10 flows. So I am well aware that there is lot of different kind use cases. In some cases it’s fine to disable debug nodes, but quite often a single flow produces tens or hundreds of messages per second. In those situations, to preserve the debug sequence I need a “snapshot” of the same message from multiple points in the flow. That’s why it’s useful to keep multiple debug nodes enabled and have a single option to pause all debug output at once.
Sorry, but I see zero value in you trying to push your own workarounds just to get around the lack of a relatively simple feature.
the old
tail -f node-red.log | grep what_have_i_donetrick ...
Yes. This is a workaround that I am currently using. I never said the problem couldn’t be worked around. The feature request exists purely because it would improve usability. I’m perfectly capable of programming without Node-RED as well, but that doesn’t mean Node-RED shouldn’t exist.
I don’t understand the logic of trying to invalidate the need for a feature just because the same result can be achieved in a much more cumbersome way by other means.
1 Like
Yes, that’s good for logging, but not very useful for development-time debugging. You know the situation where everything should work, but for some reason it doesn’t. Then you just add debug nodes after each node to see where the message flow goes south.
I also use Node-RED's custom log feature for node design debugging. Allows me to have fine-grained logs just for one node or a package of nodes. I redirect the UIBUILDER trace logs to MQTT and use a web page to display them.
But all of this is away from the original ask which was nice and simple. A way to simply pause the debug outputs.
To the point about what to do while paused, I suspect that the only sensible option that won't break node-red when dealing with lots of debug messages is to drop debug messages while paused.
The extension of this that would be nice is to allow the debug nodes to be toggled on an off without having to redeploy - this would allow us to have multiple debug nodes in a flow and to enable and disable them as progress goes through stream without having to redeploy each time
Craig
This is supported already today (each debug node has a toggle button, which doesn't require a redeploy).
I think this thread is asking for a global toggle (you can implement this yourself via gate nodes which rely on an env variable or global context var).
Hm did you do a search before posting here --> Feature Request: Pause debug panel
I guess you're not the first person and the good news is it's in the backlog for version 3.
Yep i know it is supported - but when you do it - the redeploy button is enabled - and then makes it difficult to know if there is a requirement for a real redeploy.
It would be nice if toggling debug does not trigger the redeploy process
Craig
I agree that it is totally ok to just drop messages when it is paused. And it will cause less side effects than trying do some fancy buffering logic.
1 Like
I have raised a potential PR here - Add pause button to debug sidebar by dceejay · Pull Request #5390 · node-red/node-red · GitHub
It is nice and simple :-)... just stops processing incoming messages browser side so scrolling stops... in fact for me this seems to have several benefits... when the server is "spamming" me with debug messages by hitting pause it cuts the flow and lets the browser respond (rather than being choked) - so I can edit and redeploy to stop the flood...
Also as it is just in the sidebar it isn’t changing the flow, so no need to light up the deploy button.
2 Likes
Excellent. Thank you very much. I believe this is a perfect solution on many levels and serves development-related needs extremely well.
1 Like
