Is there anything like Retry Node?

[Alexander Pivovarov]

Hi there, the real programming is about handling errors and exceptions.

So some quite cute flows becomes big and ugly when you are adding possible error handlers.

Here is an example:

I have a flow that sends a command to a z-wave controller that should turn on a light. If z-wave controller is not online, I want to retry in a while.

And I continue retrying till the success. If a new message arrives I need to eliminate the first message. (in some cases it could be more complicated. For example, if we have command toggle instead of on/off). 

I found out that I need to copy/paste/change the nodes across my flows. I am thinking about some new node(s) - Retry.

With such node(s) the same flow could be reduced a bit, but more important that I don't need to copy/paste and change lot of nodes. 

I don't know how I could connect Retry and For Retry nodes. Probably using mqtt...

Anyway, the question is - if there anything like this? and do you think it would be worth to have such node(s).

Kind regards,

-ap 

[Mark Setrem]

I like the idea, but if there are multiple retry nodes in the same flow how can you tell which one links with which?
Whilst the logic can get complicated the benefit the current flow was is to be able to visually follow the flow but this gets lost with the "retry" node.

Perhaps what is needed is a mixture, a "retry" node but still with the idea of a link to physically link the beginning and end?

[Nathanaël Lécaudé]

Did you check the catch node ? It was created specifically for error handling and you can trigger it yourself from functions using node.error("Error message", msg);

[Alexander Pivovarov]

четверг, 17 марта 2016 г., 1:40:26 UTC+3 пользователь Nathanaël Lécaudé написал:

Did you check the catch node ? It was created specifically for error handling and you can trigger it yourself from functions using node.error("Error message", msg);

If you need just to log some errors in log file Catch() would work brilliantly, but if you want re-send message to retry some work, Catch() would make flow much more complicated.

[Alexander Pivovarov]

I like the idea, but if there are multiple retry nodes in the same flow how can you tell which one links with which?
Whilst the logic can get complicated the benefit the current flow was is to be able to visually follow the flow but this gets lost with the "retry" node.

Perhaps what is needed is a mixture, a "retry" node but still with the idea of a link to physically link the beginning and end?

Good point. I am thinking about using name or some tag as an address. Visual link is also an option and it is the easiest way to do. Though the visual link makes the flow less neat....