Extend the catch node to errors not triggered by message processing

Core Development Feature Requests
1

Hi all,

Would it be possible to extend the catch node to errors not triggered by message processing?

I recently had an Omron installation that was experiencing an error because the PLC was no longer reachable, and I was surprised that I didn't receive a notification.

After investigation, the cause was that the catch node is only triggered if the call to node.error contains a message.

cc @Steve-Mcl, onClientError with undefined sequence.

1 Like
2

So, as you have realised, the error is generated not in the on input handler but by an exteranl async event so there is no msg to include: node-red-contrib-omron-fins/nodes/read.js at master Ā· Steve-Mcl/node-red-contrib-omron-fins Ā· GitHub (though I do try via tags)

It would be good if the catch node could be configured to catch those error without a message too but I have not looked in to what it would take nor considered the consequences (would likely need to be a new catch node option to stay backwards compatible)

3

If we add an option to allow any error I don't think there will be any unintended consequences.

In the done section of the Messaging API, node.error is called with the message, so our only concern is the node.error call itself. Adding the new option allows to filter which nodes should be triggered.

Another question to discuss is regarding config nodes; do we also allow them? If so, how do we integrate them into the UI? With the 'global config' flow (for global scope)?

4

For anyone else reading and need to know if an async disconnection or error has occurred in the Omron nodes, they DO update their own status. So while you cannot (currently) catch the async error, you can pick it up via a status node pointed at the Omron node(s).

5

Is anyone else interested?

@knolleary I'll be adding a concept soon.

6

Iā€™m sure some other core nodes send an error without a msg. They just create a dummy ( sensible default) msg and use that instead.

7

Yes

What's your thoughts?

8

Add an option in the configuration to allow "any error".
Allow the UI to offer config nodes.

9

Editor:

  • all nodes
    • keep the actual behavior
  • all nodes and config nodes
    • this enables anyError
  • same group
    • keep the actual behavior
  • selected nodes
    • show a new checkbox to enable anyError (allow any error other than message processing)
    • the searchBox will contain two tabs (the current flow and the global flow)
    • config nodes will be included there but I don't yet know how to visually differentiate them
    • config nodes should be filtered based on whether anyError is enabled.
    • there's no point in trying to make anyError configurable for every node, as the message either exists or it doesn't.

Or a new checkbox to include config nodes. This allows to keep all three options (too ambiguous to change)

Runtime:

  • flow.handleError will be called if the message is:
    • an object
    • undefined
    • null (optional - need to discuss)
  • catch nodes will be triggered if:
    • msg exists (actual behavior)
    • msg does not exist and anyError is enabled
  • propagate Error events from global config nodes to any nodes using this config node
    • will not be called if the scope contains the config node or if the option is all nodes and config nodes

I think I have detailed everything. Do not hesitate if you have any questions/remarks.

1 Like
10

It works fine except for one unforeseen event.

@knolleary, why is node.users always undefined for config node?

11

Draft PR submitted: