📋 Survey: logging to debug sidebar

[knolleary]

Hi,

one of the long-standing quirks of the Function node is that the only way to get a message to appear in the Debug sidebar is to use node.warn or node.error.

The problem with this approach is it puts what should be debugging comments into the log at warn/error levels. That is not a good thing for systems that monitor warn/error levels and automatically raise alerts when they happen.

The question is: how can we improve this? It isn't a hard problem to solve, but there are a few different ways it could be solved. So I'm interested in the community's feedback on the possible options.

There are three proposals:

1. Use console.log to write to the Debug sidebar. JavaScript developers will be familiar with console.log and they can already use it today to write to the log output of Node-RED directly. However - that is also why it isn't an ideal choice - it already writes to the stdout of Node-RED outside of the log handling which isn't ideal.

2. Use node.debug - we already support the other log levels from within the Function node - but they only appear in the log output if you have the log level set appropriately. The proposal here is to treat node.debug as a special case and have that appear in the Debug sidebar regardless of the underlying log level.

3. Introduce a new command, debug(), explicitly for the purpose of writing to the Debug sidebar. This would not appear in the log output.

There is a separate idea of adding the ability to control what log levels the Debug sidebar displays, but that is part of a wider review of how you can filter and select what the Debug sidebar shows. The purpose of this post is the very specific question of how to log to Debug from the Function node.

What do you think? Pick an option and vote. If you think there's another option I've missed, please add a comment.

• console.log()
• node.debug()
• debug()
• something else - please comment

[Steve-Mcl]

Hi Nick, personally, I'm not a fan of special cases (however it seems I'm in the minority having peaked the survey results ).

My vote would go to an alternative altogether. Something like...

sidebar.debug(...);
sidebar.log(...);
sidebar.trace(...);
sidebar.warn(...);
//Etc

Or...

node.sidebar.debug(...);
node.sidebar.log(...);
node.sidebar.trace(...);
node.sidebar.warn(...);
//Etc

Or something similar. Just so long as I get to specify the log level.

Having the ability to send debug messages at all standard levels would IMHO make the sidebar a bit more useful (considering future filtering/colourisation etc)

Any good?

[drmibell]

I voted for node.debug() with reservations. I know Nick asked for a vote, not a discussion, but now that the vote seems to be in, could we explore the issue?

[Paul-Reed]

@drmibell

could we explore the issue?

Well I supported @Steve-Mcl's suggestion because not everyone would be using this function for debug purposes...
I appreciate that the Leaders have strong views that the editor is not a dashboard, but using something like sidebar.log describes it's use in the widest possible context.
After all, it is the sidebar, not the debugbar...

Perhaps we should have had a discussion first, then a vote?

[TotallyInformation]

My vote was for a simple debug() function as being simple for beginners. Using node.debug() seems sensible at first sight but I can't say that I particularly like the idea that ordinary output also goes to the log unless I choose to do so. Though I'm fairly ambivalent over all, I'd be reasonably OK with node.debug() as well.

Personally, I don't like the idea of a sidebar or node.sidebar function as I don't believe that the command name actually describes the action. The sidebar is a lot more than the debug sidebar.

If anything a node.print() function name would be a lot more in keeping since it is clearly a Node-RED API function and the print verb will be familiar to everyone who has programmed in any language in the past but also self-descriptive to non-programmers.

[drmibell]

@TotallyInformation

My vote was for a simple debug() function as being simple for beginners. Using node.debug() seems sensible at first sight but I can't say that I particularly like the idea that ordinary output also goes to the log unless I choose to do so.

I started out thinking along the same lines but reached different conclusions. Beginners looking at the documentation of the function node will have already seen node.send(), node.error(), and node.warn(), so node.debug() will make sense, and debug() might seem odd and different. Since the logging level set in the default settings.js file is info, the debug output (is that what @TotallyInformation means by "ordinary output"?) will not go to the log unless the user changes the logging level. So node.debug() got my vote despite reservations that I'll try to describe in another post.

@TotallyInformation

a node.print() function name would be a lot more in keeping

Well, yes, but it still leaves the question of whether the output should go only to the debug sidebar or to the logging system as well.

[Trying_to_learn]

I'll stick my hand up only to admit I am not sure I get the entire question.

Though that may make my input invalid I feel it is something of use/interest to all and so needs to be looked at/into.

I use debug nodes and in function nodes I use node.warn( ) here and there too to help with seeing what is going on at the developmental stage of a flow.
As it evolves, those lines are removed as they no longer serve a purpose.

So I am not sure what console.log does. Yeah, I should probably look at it before posting here, but.......

I use the side bar (Right side) for debug nodes to send their messages, and for node.warn( ) to send their messages.

Looking at the 4 options:
1 console.log
2 node.debug
3 debug
3 something else

Ok, my thoughts: (and my take on what happens)
Node-Red, when running logs things. I'm not sure what, how or why. But it does as part of what could be called general operations.

There are two extra nodes: a catch and status node.
These catch any/all errors and node.status messages.
I know that error messages can be created with something like error.throw( ), but that's beyond the scope here/now.

Given their usual use, they capture their respective messages and allow user intervention.
Otherwise they are send to the right side panel.

Granted, they could be sent to their own log. I'm not up to speed with the standard of how logs are made/used.

But an option is:
debug messages - as per statusquo - are sent to the debug window (right side).
node.warn( ) messages have an option to be sent to a message log file.

Looking at the supplied information on the debug node, the options seem to not be explained too well.
1 - debug window
2 - system console
3 - node status (32 characters)

Ok, 1 and 3 make sense, but 2 isn't explained to people like me.
What is the system console? It isn't really mentioned in the information tab.

Moving on.

So my idea is/may be similar - as I explained.

When a node.warn( ) happens it is caught there is an option to send that to a log file.
Thus allowing the user to have individual logs of different levels/events.

So there is a debug log for all the debug messages, a message log for any node.warn( ) messages and (though not a valid name to use) and error log for any errors.

Then if I have a problem with a flow/tab/etc, I can put nodes in to capture specific types of data and that is saved to specific files, rather than a general generic log file which then needs to be filtered to extract the types of output desired.

That is my idea. I'm not sure I am really making sense, so I shall leave it there as I think I may (or not) have stated the case and don't, now, want to just talk for the sake of talking.

Thoughts?

[kanke]

vote debug(), only to sidebar

[tilleul]

I voted for debug() because IMHO, this should be the JS equivalent of the Debug node and propose the same options. Is the current Debug node related to the log level in settings.js (I don't think so) ?
As pointed out by @TotallyInformation, the line will be removed in the end once the debug process is complete ... and also because it's not recommended to send debug messages to the sidebar in production.

[TotallyInformation]

@drmibell

Well, yes, but it still leaves the question of whether the output should go only to the debug sidebar or to the logging system as well.

node.print() I believe would go just to the debug sidebar. After all, many people, particularly non-programmers, won't be necessarily thinking "debug", they just want to see something. You could, of course, add an optional parameter that would also copy it to the log & in that case, I think that it should be output with the minimum log level (info?) so that it would always appear.

Print statements are so common in languages that people start out with that the more I think about it, the more I think the idea has some merit. They are also common on C related languages that people may have used on the Arduino (mainly printing to the serial port). So the concept would be familiar to many people. print is therefore more inclusive language than debug.

[dceejay]

you'll be asking for node.println() next !

[TotallyInformation]

Haha, well for once I'm trying to think of the simplest solution - not like me, I know!

[Steve-Mcl]

@TotallyInformation

My vote was for a simple debug() function as being simple for beginners

The way I think about this is, if simple were the goal, then surely console.log() would be the right path (as they will see it time and time again in tutorials and examples).

However, since node-red has built in help (via the side bar) i feel its not unreasonable for them (users) to discover an alternative (as node.warn() already is and debug() would be).?

On that logic, if there is to be something other than console.log / console.debug etc, then lets make all of the possibilities available to use and all in a nice familiar fashion.

e.g. sidebar.log() / .trace() / .warn() / .error() / .info()
or
RED.log() / .trace() / .warn() / .error() / .info()
or
node.sidebar.log() / .trace() / .warn() / .error() / .info()
or
somethingElse.log() / .trace() / .warn() / .error() / .info()

I am 100% easy on what that it is, just so long as we get the whole gamut of familiar options log debug trace warn error info available with (eventually) filtering and colourisation

---

devils advocate...

Since we already have node.warn the obvious solution would be to have node.debug, node.log, node.info, etc, etc all send to the sidebar by default but suddenly lots of old projects might start spamming the sidebar

Definitely needs more thought and consideration by more than my limited view

[shrickus]

FWIW, I voted for node.debug() since it looks like it would be similar to node.warn() and node.error() -- but without the colouring

BUT, if I could wave a magic wand... then I would prefer that nothing changes code-wise -- and instead, there would be a new watch sidebar (or some such thing).

There are many times that I'd like to see what's happening inside a node, without having to alter my flow by adding/enabling debug nodes. How cool would it be to bring up a "watch" or "x-ray" sidebar, select a node to view, and in real-time see the next input msg object, any node.log() messages, and the output msg object(s). Then, when the following msg is received, it just replaces everything in the sidebar, so no history to wade through like the debug sidebar.

The idea is similar to the browser's dev console Network tab where i can select any 1 request, see all the request headers and inputs, and preview the output data and response headers. For function nodes, it might even be possible to show the intermediate variables/values that were created -- making it more obvious where your code logic is failing, without having to embed bunches of node.log(myvar) lines...

[TotallyInformation]

@Steve-Mcl

console.log()

But the expected output for that would be the console not the debug sidebar. Again, this seems confusing to non-programmers I would expect. Also, Node-RED doesn't use console.log directly, indeed many Node.js apps don't log to console and may organisations enforce that with linting.

[drmibell]

@knolleary

The proposal here is to treat node.debug as a special case and have that appear in the Debug sidebar regardless of the underlying log level.

This gave me some concern, but then it seems that node.warn() is already a special case: the output appears in the sidebar even if the logging level is set to error, so that it does not go to the console. Or am I wrong about this?

[EDIT] Actually, node.error() seems to do the same thing. It sends output to the sidebar even when logging is set to off.

[knolleary]

@drmibell

This gave me some concern, but then it seems that node.warn() is already a special case: the output appears in the sidebar even if the logging level is set to error , so that it does not go to the console. Or am I wrong about this?

The log level in the settings file is for the default console log handler.

The debug sidebar uses its own log handler which has its log level set to warn.

[drmibell]

@knolleary

The debug sidebar uses its own log handler

Are all messages sent to both handlers, or can they be fed separately?

[knolleary]

Why do you want to know? We're getting into internal implementation details which are irrelevant to the discussion.

(To answer, strictly speaking, there is one log where events are sent. You can have multiple log handlers registered that receive each event as they occur - depending on their log level configuration.)

[drmibell]

@knolleary

Why do you want to know?

Because it seemed that some of the "requirements" folks seem to have could be met by just lowering the sidebar log level to info.