Overview
This node acts as a trigger for BullMQ queues, allowing workflows to respond to jobs added to specified queues in Redis. It registers workers that listen for new jobs on a queue and then triggers the workflow execution accordingly. This is useful for integrating asynchronous job processing systems with n8n workflows, enabling automation based on job events such as task completion or status updates.
Common scenarios include:
- Triggering workflows when background jobs complete in a distributed task queue.
- Reacting to custom events pushed into BullMQ queues.
- Coordinating complex job pipelines by chaining workflows through queue messages.
For example, you might use this node to start a workflow whenever a video encoding job finishes, or to process data once a batch job signals completion via a queue message.
Properties
| Name | Meaning |
|---|---|
| Queue Source | Selects the source of the queue name: either predefined "Workflows" or a "Custom" queue name. |
| Queue Name | The name of the queue to listen to for jobs (required if "Custom" queue source is selected). |
| Respond Type | Determines how the node responds after receiving a job: - Use Last Node - Immediate - Use Respond Node |
| Options | Collection of additional settings: - Lock Duration: Time in ms to hold the job lock. - Concurrency: Number of jobs processed concurrently. - Run Retry Delay: Delay in ms before retrying a job. - Only Data: Whether to return only the job's data or full job details. |
Output
The node outputs JSON data representing the job received from the BullMQ queue. Depending on the "Only Data" option, it either returns just the job's data payload or the entire job object serialized to JSON.
The output JSON includes:
- Job data fields (custom per job).
- A
lockTokenused internally for managing job locks.
If the "Respond Type" is set to "immediate," the node outputs a special response indicating immediate acknowledgment without waiting for further processing.
No binary data output is produced by this node.
Dependencies
- Requires a Redis server connection configured via credentials in n8n.
- Uses the BullMQ library to interact with Redis queues.
- Needs proper Redis credentials configured in n8n to establish the connection.
- The node depends on helper functions bundled within its utilities for creating workers and managing Redis clients.
Troubleshooting
- Queue Name Missing: If no queue name is provided (and not using the default workflow ID), the node throws an error. Ensure the queue name is set when using a custom queue source.
- Missing Lock Token: Errors occur if the job lock token is missing during processing; this indicates internal issues with job locking or worker setup.
- Job Waiting Error: If a job is still in a waiting state, the node throws a delayed error to avoid premature processing.
- Last Node Execution Data Missing: When using "Use Last Node" respond type, errors may arise if the last executed node or its run data is unavailable. This usually means the workflow did not execute as expected.
- Redis Connection Issues: Credential test failures or connection errors indicate misconfigured Redis credentials or network problems.
- To resolve these, verify queue names, ensure Redis credentials are correct, and check that jobs are properly enqueued and not stuck in waiting states.