Concurrency Lock Check [apm] icon

Concurrency Lock Check [apm]

Check if a workflow is running and create lock if not
Join our community

Overview

This node checks whether a workflow is currently running by using a Redis-based concurrency lock mechanism. It attempts to create a lock key in Redis for the specified workflow ID within a given namespace. If the lock exists, it indicates that the workflow is already running; if not, it creates the lock and allows execution to proceed.

Common scenarios where this node is beneficial include:

  • Preventing multiple concurrent executions of the same workflow to avoid race conditions or resource conflicts.
  • Coordinating distributed workflows or tasks that must not overlap.
  • Implementing simple distributed locking mechanisms using Redis.

For example, before starting a workflow execution, this node can be used to check if another instance is running. If no lock exists, it sets one with a TTL (time-to-live) to automatically release the lock after a timeout, ensuring stale locks do not block future runs.

Properties

Name Meaning
Namespace Redis namespace to group keys, e.g., "executions" or "workflows:executions".
Workflow ID The unique identifier of the workflow to check or lock. Defaults to the current workflow's ID.
TTL (Seconds) Time-to-live for the lock key in Redis, in seconds. After this time, the lock expires automatically. Default is 120 seconds.
Ignore Lock in Test Mode Whether to bypass the lock check when running the workflow in test mode, allowing execution regardless of existing locks.

Output

The node has two outputs:

  1. Idle (first output): Emitted when no lock exists or when a new lock is successfully created. The output JSON contains:

    • workflowId: The workflow ID checked.
    • lastUpdate: Timestamp (formatted as yyyy/MM/dd HH:mm) when the lock was set.
    • testMode (optional): Present and set to true if the node is running in test mode and ignoring the lock.

  2. Running (second output): Emitted when a lock already exists, indicating the workflow is currently running. The output JSON contains:

    • workflowId: The workflow ID checked.
    • lastUpdate: Timestamp of when the existing lock was last set.

No binary data is output by this node.

Dependencies

  • Requires a Redis server accessible with host, port, and password credentials.
  • Needs an API key credential or equivalent authentication configured in n8n to connect to Redis.
  • Uses the ioredis library internally to interact with Redis.
  • Relies on the luxon library for timestamp formatting.

Troubleshooting

  • Missing Redis Credentials: The node will throw an error if Redis credentials are not provided or invalid. Ensure proper credentials are configured.
  • Empty Workflow ID or Namespace: Errors occur if either the workflow ID or namespace input is empty or whitespace. Provide valid non-empty strings.
  • Redis Connection Issues: Network problems or incorrect Redis configuration may cause connection failures or timeouts.
  • Lock Not Releasing: If the TTL is too long or the node crashes before releasing the lock, the workflow might remain locked longer than expected. Adjust TTL accordingly.
  • Test Mode Behavior: When "Ignore Lock in Test Mode" is enabled, the node always allows execution even if a lock exists. This can lead to concurrent runs during testing.

Links and References

Discussion