The MC Queue node is used to manage long running tasks. It takes the payload of the incoming message, it stores it a SQLite queue and redirect the stored payloads to the output pin one by one, at regular interval.

The typical use is broadcasting the same message to a large set of users with a regular pace, accepted by the chat platform, the broadcast is split in single tasks, it can be stopped or resumed, it’s stored in a database and survives across Node-RED’s restarts and can be inspected with the Mission Controls queues panels.

Simple send to recipients flow

Simple send to recipients flow

Name Description
name The name of the queue, if left blank is default
initialState The initial state of the queue: running or pause. If running it will start consuming elements from the queue as soon as the flow is deployed
type The type of the queue: sequential or stops after each element. If sequential it will continue to consume elements from the queue at a pace defined by delay, otherwise the queue is paused after each consumed element.
delay The delay in ms between elements consumed by the queue. It also accepts variables from the flow and global context, for example {{flow.myDelay}} or {{global.someDelay}}

It’s possible to issue commands to the queue with a simple inbound message

{
  mycommand: true
}

Available commands

Command Description
start Start a paused queue
next Consume next element of the queue
pause Pause a running queue

The stops after each element queue type is useful in scenarios where each element of the queue needs to be extracted when the previous task is completed, for example a FTP server which doesn’t allow concurrent uploads

Retroaction to execute one element at a time

Retroaction to execute one element at a time

Here a simple retro-action of the function node which sends to the output a msg { next: true } which triggers the extraction of the next element of the queue only when the previous element is uploaded completely.

The payload added to the queue can contain a taskId, which identifies the task, if a task with the same taskId already exists in the queue, then the new payload will be merged with the existing one. If no taskId is provided, then a random one is assigned.