Persistence after crashing

#1

Hi there,

I have been looking around but unable to find an answer to this. Is there a way for the state of a flow to be persisted?

For example, I have created a flow that accepts an HTTP request and returns a response. At the same time, it then passes the payload to different nodes which do a variety of different processes etc.

However, if the payload is (say for example) 40% through the flow and the node process crashes, when I restart Node-RED is there a way for it to continue where it left off, or would it be lost forever and a new HTTP request have to be made?

Thanks,
George

0 Likes

#2

Hi @georgehanson.

There is no built-in way to resume a flow following a crash.

In the case of an HTTP request, if NR crashes then the node process dies and the OS will close the socket. There's simply no way for NR to be able to restart and respond to that same request.

1 Like

#3

Thanks for quick the response, I suppose that makes sense when you think about it.

Nevertheless, Node-RED is great so thanks for making it open source :slight_smile:

0 Likes

#4

Crashes should be extremely rare. I can't remember the last time that my 'production' node-red crashed. Are you getting regular crashes?

0 Likes

#5

No, but I haven't yet tried sending hundreds of requests to it yet. I was just curious in the event of the Node process crashing how it would handle it.

0 Likes

#6

Do you necessarily have to send http requests? Otherwise, if you instead could send requests via a MQTT broker, you could design it so the latest request will be executed when NR reconnects to broker/topic after a crash if you send requests with the retain flag set

0 Likes

#7

It's mainly going to be a flow which runs upon a web hook from a third-party source.

0 Likes

#8

Yes, understood, but if you could capture those http requests and "convert" them into request messages sent to a mqtt broker, the flow would only react to requests originating from mqtt. You might need to write some "frontend" that handles this conversion. I do not know but maybe you also would need to stop sending http requests when/if NR is down? Or it is ok to lose such requests?

http requests -> "frontend" -> mqtt "request" message with retain flag set -> broker -> NR mqtt subscription -> NR flow etc

You could then let both the "frontend" and NR monitor each other that they are running. They could both restart each other if necessary (it's maybe not so likely they would crash at the same time)

As maybe an easier solution you could let the "frontend" FIFO buffer requests if NR is down and send them as soon as NR is running again

http requests -> "frontend" with FIFO buffer -> NR flow

I would write the "frontend" in Python (but that is just my personal opinion and choice)

0 Likes