Help with message queuing (maybe a repeat)

[Trying_to_learn]

I went back through my history to check and couldn't find anything, so this is a post asking for help with messages.

I've got into voice messages and not allowing them all to play at once is a challenge.

I have a gate (foreign) node set to queue.
It gets tricky but most of the time it works.

What is happening - better discription:

Here goes:
A messages is received.
It is queued.
A status node parses the message from the gate node and if there is only 1 message it triggers a next message message to be sent to the gate (more more so queue) node.
This then sends the message on to the TTS node.
When that is done - and all is good - it too sends a next message back to the queue node so if there is another message, it is sent.

The problem is that it is:

If - while the message is being handled by the code AFTER the queue node the problem happens.

As it is no messages in it's queue, the status node and associated stuff don't see any messages and so this next/new message is then onsent and it steps on the previous message.

I'm hoping Sod's law steps in and after my posting, I work out a solution.

And saying that, I may have now thought of the solution.

This is a BASIC overview of the structure.

My thought is to move the wire coming back (indicating all good and send next message) from the queue node to the message queue counter node.

[Colin]

This is the standard flow for sequential operations, using a Delay node with its Flush capability. Open the Comment node to see more details of how to use it.

[{"id":"b6630ded2db7d680","type":"inject","z":"bdd7be38.d3b55","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":140,"y":480,"wires":[["ed63ee4225312b40"]]},{"id":"ed63ee4225312b40","type":"delay","z":"bdd7be38.d3b55","name":"Queue","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"minute","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":310,"y":480,"wires":[["d4d479e614e82a49","7eb760e019b512dc"]]},{"id":"a82c03c3d34f683c","type":"delay","z":"bdd7be38.d3b55","name":"Some more stuff to do","pauseType":"delay","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":800,"y":480,"wires":[["7c6253e5d34769ac","b23cea1074943d4d"]]},{"id":"2128a855234c1016","type":"link in","z":"bdd7be38.d3b55","name":"link in 1","links":["7c6253e5d34769ac"],"x":95,"y":560,"wires":[["3a9faf0a95b4a9bb"]]},{"id":"7c6253e5d34769ac","type":"link out","z":"bdd7be38.d3b55","name":"link out 1","mode":"link","links":["2128a855234c1016"],"x":665,"y":560,"wires":[]},{"id":"b23cea1074943d4d","type":"debug","z":"bdd7be38.d3b55","name":"OUT","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":670,"y":400,"wires":[]},{"id":"d4d479e614e82a49","type":"debug","z":"bdd7be38.d3b55","name":"IN","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":470,"y":400,"wires":[]},{"id":"3a9faf0a95b4a9bb","type":"function","z":"bdd7be38.d3b55","name":"Flush","func":"return {flush: 1}","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":190,"y":560,"wires":[["ed63ee4225312b40"]]},{"id":"7eb760e019b512dc","type":"function","z":"bdd7be38.d3b55","name":"Some functions to be performed","func":"\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":550,"y":480,"wires":[["a82c03c3d34f683c"]]},{"id":"e35f37deeae94860","type":"comment","z":"bdd7be38.d3b55","name":"Set the queue timeout to larger than you ever expect the process to take","info":"This is a simple flow which allows a sequence of nodes to be \nprotected so that only one message is allowed in at a time. \nIt uses a Delay node in Rate Limit mode to queue them, but \nreleases them, using the Flush mechanism, as soon as the \nprevious one is complete. Set the timeout in the delay node to \na value greater than the maximum time you expect it ever to take. \nIf for some reason the flow locks up (a message fails to indicate \ncompletion) then the next message will be released after that time.\n\nMake sure that you trap any errors and feed back to the Flush \nnode when you have handled the error. Also make sure only one \nmessage is fed back for each one in, even in the case of errors.","x":270,"y":360,"wires":[]}]

[Trying_to_learn]

Thanks.

That looks familiar.... (As I said, I've probably asked this but couldn't find the thread)

I've stored that in my archive for future reference too.

There is a catch, that the processing time on the messages is unknown as they can range in size/length/time from short to ...... LONG.

But I guess I just set the timeout to LONG+

[Colin]

What do you mean by LONG+?

[Trying_to_learn]

Well, I'm not sure. I will have to see what happens with what I have set now and if they start to overlap, I'll increase it.

And sorry for marking the wrong post as the solution.
I've now changed it to your post.

[Colin]

I meant do you mean minutes long or hours?

[Trying_to_learn]

No.

I was also being .... (how do you spell it?) facetious?
(sarcastic?)

No, probably more minutes.