Guaranteed Delivery flow with fileStorage gets stuck often

[jakonnode]

Refer to this thread

Node-red-contrib-msg-queue - Only storing not forwarding w/ active connection

Colin - You are (embarrassingly) fast in responding and I'm quite obliged. _/_ On limits, it is quite unambiguous on your documentation. I missed. My bad. [image] For our IoT applications, the edge devices is in remote location and in an industrial environment where network connectivity and handling is a challenge. There are times where we have two-three days of no connectivity in which case it could be of order of few GBs(extreme case and support estimation).

Using the below flow for guaranteed delivery with FileStore backing. Over time, it gets stuck with state being "waitingForOKFail" and was never able to recover from this. This happens for no reason that I couldn't triangulate - there is no mqtt server failure.

Anyone has faced this issue before - any likely way out of this. Can this be because of file lock issue or something like that?

[Colin]

It should not be able to get stuck. What is the mqtt complete node?
You could install the flogger node and log the messages and see how it gets stuck.
In the meantime you can manually release it by injecting a Fail message with an inject node.

[Colin]

@Colin

What is the mqtt complete node?

If course it is a Complete node attached to the mqtt node.

[jakonnode]

I have added a floggernode to track injecting message. But not sure how this gets. After (re)deploying few times it got stuck again.

Not sure how to inject a Fail message - could you please elaborate? msg.control="FAIL" or something like that?

[Colin]

Use the flogger node to show what is happening at multiple places in the flow, into mqtt, out of the complete node, out of the trigger node. You don't need it at the front where you have it.

@jakonnode

how to inject a Fail message

The same message that comes out of the FAIL change node. In fact I think you can just inject anything into the front of the fail node.

[jakonnode]

Thanks Colin. It did release all the messages when I injected some timestamp. But I have no clue as to how that happened.
Is it because it was waiting for either Ok or Fail - and in this case Fail (control=fail) helped move it? I saw it so?
Awesome.
I used the flogger to backup the messages. I will try adding another logger purely for debug to find out why it is getting stuck.
Thanks a bunch.

[Colin]

Send them into one flogger so you can see the sequence.

@jakonnode

Is it because it was waiting for either Ok or Fail

Do you actually understand how the flow is supposed to work?

[jakonnode]

@Colin

Send them into one flogger so you can see the sequence.

Wanted the data backup in one log file and all debug in another file so that it can be handled separately and easily with different policies.

@Colin

Do you actually understand how the flow is supposed to work?

Yes. A while back I had looked at it - I forgot some of the details. Again I looked at the subflow template (state engine) yday to understand how triggering a fail message would process the pending ones.

[Colin]

@jakonnode

to understand how triggering a fail message would process the pending ones.

Triggering a fail tells it the the previous one failed, so it tries it again, after the timeout you specified.

I am not sure what you are saying about flogger. From my point of view the purpose is to record what is happening so that you can look back and see why it got stuck. Can you export and post here the flow please, the nodes around the subflow. I want to make sure it is correct.