... or should core have a dedicated node to catch warning messages?
There are a few nodes that spit out warnings that can sometimes be critical to smooth operation however they cannot be caught and programmatically actioned nor easily sent to a user (via email/telegram etc). Sometimes, you just want to catch and silence them for other debugging reasons.
So the question is, should we be able to catch warnings?
There may be a technical reason as to why a warning cannot easily be retro'd to be catchable but I thought it worth the ask?
It's a good point. Would need to be added as an option and default to off, of course, to prevent messing up old flows. But seems like a worth-while addition if it can be done without too many overheads. Not sure it can be done though?
There are also log events that do not appear in the debug sidebar but are written in the Node-red log (and can be seen using the node-red-log command).
31 May 18:43:20 - [info] Starting modified flows
31 May 18:43:20 - [info] Started modified flows
31 May 18:43:24 - [info] [function:node.log("Lunar Eclipse Starts")] Lunar Eclipse Starts
How about catching these events too?
That would let us branch off to trigger some nodes without explicitly drawn wires and without debug output, controversial but potentially useful.
what a node that can generally consume debug messages? Something like the status node that consumes status messages of other nodes?
Would generalise what you are suggesting plus avoid modifications of the catch node that - as the name suggests - should deal with exceptions and not warnings.
catch is synonymous withtry & exception handling in programming terms but in the definition of the word itself, it still kinda fits (catch errors, catch warnings etc)
It's why I raised this as a topic, to see where it leads & see if I can get a level of consensus.
Without discussion, i would probably go with expanding catch node (in the English sense) but I totally expect a left of field madcap idea to sway me
You can of course just use a watch node to tail the full log and filter it however you want...
I would argue that log and warn should not affect the flow of data in the flow and are purely informational to help the developer understand what is happening. Whereas error does actually cause a different fork in the code to be run. (as per a try/catch etc).
There is an ongoing task as to how to better handle showing connections to catch and link nodes - we absolutely want to draw/show wires not remove them even more.
Yea, but far from ideal. It also doesn't silence the warnings in debug log and we have no way of silencing them (very annoying).
The issue I see in some contribs nodes is that they use warnings when they should be errors (and sometimes the reverse).
I don't see the harm in having the ability to catch any log level in flows. There have been many times I've had a contrib node warn about "no connection to PLC/system/thing" but I was not able to know that programmatically (so couldn't take action or report it to a monitoring system etc)
I wonder (if there is no consensus) if a contrib node could intercept logs and handle this
As a reminder, if the message object doesn't exist, the catch node can't retrieve the error message. That's why I wanted to broaden the scope of the errors.
I'm not sure that, technically speaking, a warning is synonymous with an action.
At least on a Pi you can do this with an exec node to run node-red-log in spawn mode and a switch node to filter out interesting lines.
An inelegant approach but it does work, as long as the external process doesn't die.
I don't know if node-red-log is available on other platforms which don't use journalctl logging.
As people may be aware, I am a great fan of event-driven flows. Yes, I know that not everyone is.
However, I don't think this one would be right.
Node-RED already supports custom logging processes and that, in my view, would the "right" way to handle this. Create a custom log handler that filters for the required log messages and outputs them (or a processed version of them) to MQTT.
I've already got one of these that outputs uibuilder trace messages to MQTT allowing me to create a simple flow that shows the messages on a web page.
I think that there may be an argument for exposing warn outputs but agree that general log outputs should probably not.
However, a function that could be used in a custom log handler that would trigger a flow somehow - that might be interesting. Then it would not be used to grind the whole log output but only a filtered subset.
As mentioned above, this is neither necessary, nor a good thing to do - lots of overheads.
Can I ask how that differs to my earlier suggestion of having a debug-log node similar to the status node?
Is that what you're suggesting?
EDIT:
Btw I did notice that the status node is implemented so that each status call checks for the existence of a status node - as opposed to an event being raised and a status node being a listener for specific events.
I say this because I wanted to implement a debug capture node (for my unit testing package) but can't figure out how to create a event capture mechanism because the status node was implemented based on events.
Fyi, I created a quick capture node --> capture debug node. It generates a msg for each debug message generated. It also implements some basic logic to avoid endless loops if a debug node is attached to it.
As shown, it also captures error and info messages in the debug.
How does it do this?
The core of the node is this:
module.exports = function(RED) {
function Corecapture_debugFunctionality(config) {
RED.nodes.createNode(this,config);
var node = this;
var cfg = config;
var handler = (msg) => {
if (msg.topic != "debug") { return }
if (!msg.data || typeof msg.data != "object") { return }
// ignore any debug messages generated by debug nodes directly connected
// to this node else endless loops are created.
if (node.wires[0].indexOf(msg.data.id) > -1) { return }
if ( msg.data.format == "Object") {
let d = JSON.parse(msg.data.msg)
if (d._capturedebug) { return }
}
if (msg.topic == "debug" && ( (msg.data && !msg.data._capturedebug) || !msg._capturedebug )) {
node.send({
_capturedebug: node.id,
_msgid: RED.util.generateId(),
debug: msg.data
})
}
}
require("@node-red/util").events.on('comms', handler)
node.on('close', function() {
require("@node-red/util").events.off("comms", handler)
});
}
RED.nodes.registerType("capture-debug", Corecapture_debugFunctionality);
}
I was unsure if you were referring to a core or contrib node. I was explicitly asking (trying anyhow) if this is not accepted into core, could a contrib node be an interceptor while implying it would/should also act like a core node (with the ability to mute the warnings like the core catch node does).
Nice, that at least gives users the ability to react to warnings in an event based way even if it cannot mute the warning in the sidebar.
Side note:
I have never written a custom debug log handler myself but that may be another possibility - however I suspect it will not prevent sidebar entries (like a catch node does)!
If a contrib node can do a job why add to core? adding to core means that it has to be maintained by core contributor, needs to be updated with new versions of nodejs, needs to be debugged if in error, is harder to update/extend ... etc
I say this as someone who sees a slim core and fat contrib as preferrable approach - i.e. something like the linux kernel. If contrib nodes become outdated, then fork and update - as Dave said above.
I won't be saying this if NR didn't have such good support for contribs and plugins - I would extend this framework so that contrib nodes can do more. I.e. as in this case, there is no documentation how to capture the debug messages before they sent to the frontend and that API might change with future versions - I would solidify that API and maintain that instead of maintaining the node that uses that API - in the core.
But that's my perspective.
Isn't there a debug-panel filter mechanism for that? Perhaps extend that so it's possible to filter a set of individual nodes - if mute is the desired action.
I would say "what would Jonny Ive do..." but then I saw what he did to Ferrari 
