Message tracing for beginners

Developing Nodes
1

Hi there,

I want to trace messages through a flow as an aid for beginners to understand how messages are passed through NR flows. I have already done this on the headless in-browser only NR but now I want to build a plugin that does the same the serverful NR.

Having been pointed to the hooks API by Nick, I created a plugin with the following bit of code:

module.exports = function (RED) {
  function ConfigMsgTracerFunctionality(config) {
    RED.nodes.createNode(this, config)
    console.log( "REGISTERED TTPE MSGTTACER")

    RED.hooks.add("onReceive", (evnt) => {
      try {
        let nde = RED.nodes.getNode(evnt.destination.id)
        nde.status({ fill: "green", shape: "ring", text: "msg received" })
        setTimeout( () => {
          nde.status({})
        },1000)
      } catch(ex) {
        console.error(ex)
      }
    })
  }
  
  RED.nodes.registerType('MsgTracerCfg', ConfigMsgTracerFunctionality);
}

This works perfectly, just what I want except .... the hook is added each time the plugin is registered and that is unfortunately each time I do a deploy.

The question is: how do I prevent the hook from being added multiple times?

EDIT: what I also noticed that without the try {...} catch { }, I can actually prevent messages from being passed around in NR, i.e., an exception in the hook will prevent the router from continuing. That should probably not happen and instead the hook dispatcher should wrap those callbacks in it's own try/catch ....

/cc @knolleary

2

@marcus-j-davies has already created this kind of plugin :wink:

Note: this kind of plugin should only be used for debugging because the hook takes a beating.

3

@gregorius that isn't a plugin - that's a palette node.

Plugins are ways to add code to the runtime and/or editor without needing to register a node that the user has to add to their flows and deploy.

Here is how the Flow Debugger registers itself in the runtime:

And in the package.json file, it is identified under a plugins section:

4

Cheers! That worked but I also did a remove of the hook just in case:

module.exports = function (RED) {
  function msgTracerOnReceiveHook(evnt) {
    try {
      let nde = RED.nodes.getNode(evnt.destination.id)
      nde.status({ fill: "green", shape: "ring", text: "msg received" })
      setTimeout(() => {
        nde.status({})
      }, 1000)  
    } catch (ex) {
      console.error(ex)
    }
  }

  RED.plugins.registerPlugin("msg-tracer-plugin", {
    onadd: () => {
      RED.hooks.remove('onReceive.msgTracer')
      RED.hooks.add("onReceive.msgTracer", msgTracerOnReceiveHook)
    }
  })
}

and in the package.json it's a plugin :+1:

5

And now I know how he built it :wink:

Thanks for the heads up but thanks to doing it myself, I learnt how to create a plugin - properly!

6

Mine was a plugin (in the end)
that highlighted the wiring loom, as messages travelled along them.

It was a POC, never publicly released.

I still think it had massive value, but had concerns with UA performance.

7

Hi @gregorius,
You might also have a look at my node-red-contrib-msg-profiler node, which does message tracing and profiling through a flow (based on hooks).
P.S. it is not published on npm.

8

looks good and something that will become more important - when more people start using NR!

My delving into the world of NR hooks happened because someone (on the slack channel) was asking about having a monitor node to replay messages to test flows. But they also don't seem to have any financials to pay for the development of such a node ...

9

Just to repeat (and expand on) what I said in the very same slack conversation:

I strongly feel there is a place for some form of these tools in the core of Node-RED; some basic capabilities that will greatly enhance the flow editing experience. Having lots of people create their own plugins is a great learning experience for them, but it doesn't moving the core Node-RED forward at all. We already have the Node-RED Flow Debugger plugin - a lot of these are natural extensions of what it does already - but we haven't had a single contribution to that plugin.

There's nothing wrong with that; its open source and no-one is under any obligation to contribute. It just puts the burden on a small few to try to move things forward when there's already a long wish list of items like this.

10

I can understand your point but most of the stuff I'm doing is extremely niche, e.g., turning the editor into a dashboard or using it as a MindMap or using it for creating decorative flows (i.e. art!) or even converting flows into editable 3D flows. And I'd rather be doing that than creating MVPs for others for exactly zero financial benefit - personally I have exactly zero use-cases for a monitoring node.

When there is something that I think is useful, it remains in pull request state without feedback nor comment - so it doesn't seem to be important for others - fair enough, all good. If I do need that feature, then - thanks to the incredible wonderful flexibility of Node-RED - I can install my own node & this is super simple (especially since I can use my own flowhub integration).

And similarly for msg tracing that is now part of the 0.8.1 version of the introspection package - there is now a checkbox that I can toggle message tracing on/off. If someone whats to put this in the debugger, then there is the commit that basically describes the functionality.

But I have no desire to get involved in project management overhead for something that I do for fun and giggles.

11

With version 0.8.4 I've made this a little more useful by having a list of nodes and how many times they were called:

msgtracer2

By clicking on the node, the node is highlighted and with a double-click the nodes edit panel is opened.

BTW yes this will slow down your editor if you have very busy flows and yes this shouldn't be done at home and kids: don't do this without parental consent. This is definitely a adults-only feature.

EDIT: Message tracing can be toggled on/off without redeploying the flow and the hook is removed in the backend when it's off - there is zero backend overhead when msg tracing is deactivated.