In a previous post about the issue, I didn't find any cause about node-red stopping the FSM loops after some time, but I've finally figured it out and already raised an issue in the NPM page of the node.
As I pointed out in my previous post, I often had the problem that the CPU/memory usage in node-red grew up quickly, and some of the loops were interrupted after some time, or the whole node-red application crashed (I guess several concurrent messages had grown too much without reaching the maximum size, but node-red couldn't handle all of them at once).
Turns out, I was merging two of my big projects, and I had to do several updates to the offending project that involved looking not just at msg.payload but the whole message. That was the point I realised that the node did not behave as in its documentation.
In the original documentation, states that msg.payload.trigger "Contains the original message that triggerd the state change", but I had never seen any indication of an msg.payload.trigger object.
Looking upon the whole message, though, I realised that there was an msg.trigger object instead, and yes, it contained the previous trigger message.
The problem is that finite-statemachine node does not clear msg.trigger of the previous trigger message before assigning it to the output msg.
This causes, in a loop, that the output message contains the input msg in msg.trigger, that contains the previous input msg, that contains the previous input msg and so on, recursively, until node-red runs out of memory and crashes, or until the msg breaks the max msg size and stops.
With this new piece of information, that does not appear in the documentation, I cleared msg.trigger in the function node immediately before the input of the finite-statemachine node ( could be also done with a change node):
msg.trigger = {};
Hopefully, the documentation can be changed to warn others of this. Ideally, as I point out in my issue, something could be done to add an optional checkbox for the automatic clearing of the msg.trigger of the input message (should be cleared by default, but the nested messages can be a very powerful tool for short-term debugging).
