[ANNOUNCE] @waldbaer/node-red-retry

Share Your Nodes
1

Hi,

I’m excited to announce the release of my new node, designed to simplify the implementation of retries within Node-RED flows.

Motivation

I use Node-RED to manage my smart home, which involves interacting with various devices, bus systems, internet services, and more. Unfortunately, some of these devices or services occasionally fail to respond, return errors, or become unreachable.

Since many of these systems are essentially "black boxes" for me, I can’t always address the root causes. Instead, I want to build a system that is as robust as possible against these sporadic issues.

In many cases, simply retrying the request or query to the device or service solves the problem.

However, I couldn’t find an existing Node-RED node that simplifies implementing the necessary retry loops. The only resource I came across was the cookbook article, 'Automatically retry an action after an error', which provides some guidance on implementing a retry mechanism.

A key limitation of the pattern described in the article is that it can lead to an infinite loop if the error can’t be resolved through retries. Additionally, the pattern only works if the caught msg contents are not altered by the flow.

Solution

After experimenting with a subflow template, I decided to develop a new node that simplifies creating retry flows and loops. This node essentially stores the last valid message and resends it if an error is reported. The retries are capped at a configurable maximum and can be optionally delayed (similar to the Delay node).

This is the new born node:

Future

There are several ideas for future improvements:

  • Independent retry state per msg.topic
  • More advanced retry strategies (e.g., N fast retries followed by M slower retries)
  • Dynamic control through msg properties.
    • Set the retry strategy using msg.strategy
    • Set delay time using msg.delay

I hope this node will be useful to many other Node-RED enthusiasts.

I'm eager to receive constructive feedback!

4 Likes
2

Great use of the catch Node @waldbaer

One feature I would like to see, is a 2nd output pin, that is used to sink the final retry (upon failure), as the end user, can then route it later for investigation of the cause.

A node like this, will be a potent mix when used with my Semaphore+ Node

node-red-semaphore-plus
(I won't link, in fear of hijacking your reveal)

Great work! :+1:

3

@marcus-j-davies do you want to get the last retried msg on the second output or actually the last error msg which is not triggering another retry?

For the second case the retry node is already re-throwing this last error message by itself in case the max. number of retries is already reached. As shown in the example another catch node for the retry node itself can be used to get this last error msg for possible post-mortem handling.

1 Like
4

One (very minor) thing.

The link to examples is using relative paths in the readme - the markdown renderer in the flows website, will only (purposely) target the master repo and using raw when its NOT an .md extension.

It's a quirk I raised a while ago (and hence the need to target master/raw) , it's no biggy, but thought id mention it

Screenshot 2024-09-06 at 18.01.42
Screenshot 2024-09-06 at 18.01.421541×1072 81.4 KB

5

What I mean is: If, on the final retry, it still fails, to pass it out to a 2nd Pin.

Example: I will want to store the error, if it failed 3 times for example (the 4th failure, to be reported out on pin 2)

A kind of

I tried this darn thing 3 times, so I will instead send it to be looked at by an admin
(out on pin 2)

Im just thinking out aloud :innocent:

6

Could be quite handy. :+1:

Isn't it convention here to put "contrib" in the names of these nodes?

7

Not now.

The rulings have changed : as long as its scoped something like : @dev-name/%
One is free to use anything they see fit:

But as a guide : @dev/node-red-<magic>

As long as it contains the node-red keyword (and is a Node RED Node) it will get indexed

This only applies to NEW nodes being introduced

1 Like
8

Did you see node-red-guaranteed-delivery (node) - Node-RED? I think it should be able to solve your problem.

9

@marcus-j-davies
I added support for second output port with the just released version 1.1.0.

From the Help:

If the max. number of retries is exceeded the retry node forwards any subsequent error msg to the second output port. Optionally the error msg can be re-thrown as error by the retry node if option 'Throw as Error If Retry Limit Is Exceeded' is enabled.

1 Like