How flush messages queue

Dear all,

I moved recently to Node-red 1.0 and I noticed a difference of behavior in the messages exchange, due to asynchrone vs synchrone implementation.

Here is my use case , I have a node A sending (at high frequency ) messages to node B.
I see now ( with node red 1.0) that when i redeployed my flow (start/stop flow ) the last message sent by A before the redeploy is received by B after redeploy.

If i add in my settings.js the following option : runtimeSyncDelivery: true , I'm coming back to the previous behavior.

My question is : is there a way to flush messages when stopping the flow ?

Thank you.


I think you are hitting a timing window that has always existed, but the changes in 1.0 have possibly made it easier to hit.

When the flows are stopped and restarted, we'd expect 'in-flight' messages to be dropped because their target nodes don't exist. But if there are enough in-flight messages, then the new instance of node B could come into existence before the in-flight messages have drained. That's my guess as to what you're setting, but I need to think through this a bit.

There is no way to flush the messages as you describe.

Thank you for your answer.
I need some clarification on your sentence : " if there are enough in-flight messages" , for me there is only one message sent from node A in the queue before stopping flow , and this message sent to node B after restart of the flow.

You had said node A is sending at high frequency. Only having one outstanding message doesn't sound high frequency to me.

Can you share a simple flow that demonstrates the issue? As I said, I'm only guessing at the possible cause based on your description.

So I think I need to explain a little bit more.
I have only 2 nodes in the flow , one inject node ( node A ) sending every millisecond a message , and my custom node B processing this message. In this node B i created a child process to manage heavy calculations.

What I understood by adding some log is that I have the following steps:

starting flow
started flow
Message 1 sent by node A
message 1 received by node B instance Xb.
Message 2 sent by node A
message 2 received by node B instance Xb.
Message 3 sent by node A
message 3 received by node B instance Xb.
Message 4 sent by node A
stopping flow
stopped flow
starting flow
started flow
Message 4 received by node B instance Xb ( instance of node B created during the previous flow deployment , not completely closed ?).

I'm killing this child process during a close of the node, but i suspect that it could take some time ,and explaining that the first instance of this node B is still alive after stop and start of the flow.

Do you confirm that we can have some "ghost" nodes after a restart of the flow ?

thank you.

Does your node use the 'done' callback of thr close event to tell the runtime when it has finished cleaning up? If not, it is entirely possible the old instance will still exist longer then it should.

1 Like

That's solving my issue. My child process name is computeData. By adding a listener on exit , I'm really closing properly the node before restarting the flow. Thank you !!

node.on("close", function(done) {"nodes-started", handler);
node.computeData.on("exit", () => {

1 Like