Overview
This node, named "Wait For Executions," is designed to monitor the status of sub-workflow executions within n8n. It waits for these executions to complete before proceeding, allowing users to coordinate workflows that depend on the results of other asynchronous executions.
Common scenarios where this node is beneficial include:
- Waiting for multiple triggered sub-workflows to finish before aggregating their results.
- Implementing retry logic and timeout handling for sub-workflows that may take variable time or could fail.
- Managing complex workflow orchestration where downstream steps depend on the success or failure of prior executions.
For example, if you have a main workflow that triggers several sub-workflows to process data in parallel, this node can be used to wait until all those sub-workflows have completed (successfully or not) before continuing with further processing or error handling.
Properties
| Name | Meaning |
|---|---|
| Wait For All Executions | Boolean option to either wait for all sub-executions to complete before passing output (true), or pass items one by one as they finish (false). |
| Retry Limit | Number specifying how many times the node should check the execution status before considering it failed. |
| Execution Timeout (Seconds) | Maximum allowed execution time in seconds before marking an execution as failed due to timeout. |
Output
The node outputs three separate streams:
done: Items representing sub-executions that completed successfully. Each item's JSON will include an
execution_outputfield containing the result data from the sub-execution, specifically the output of the last executed node in that sub-workflow.failed: Items representing sub-executions that failed, were canceled, crashed, timed out, or exceeded retry limits. The
execution_outputfield contains error details explaining the failure reason.processing: Items representing sub-executions still running or waiting. These are passed through when not waiting for all executions or when some executions are still in progress.
Each output item corresponds to an input item enriched with additional metadata about the sub-execution's status and output/error data.
Dependencies
- Requires an API key credential to authenticate requests against the n8n instance's REST API.
- The node makes HTTP GET requests to the
/executions/{id}endpoint of the n8n API to fetch the status and data of sub-executions. - The base URL for the API is taken from the provided credentials and sanitized to remove trailing slashes.
Troubleshooting
No sub-execution ID found in item metadata: This error occurs if the input item does not contain a valid sub-execution ID in its metadata. Ensure that upstream nodes correctly set this metadata.
Execution exceeded retry limit: If the node retries checking the execution status more times than allowed by the "Retry Limit" property, it marks the execution as failed. Increase the retry limit or investigate why the execution is taking too long.
Execution timed out: If the execution runs longer than the specified "Execution Timeout (Seconds)," it is considered failed. Adjust the timeout value based on expected execution durations.
Execution not found: If the sub-execution ID does not correspond to any existing execution, the node reports failure. Verify that the execution IDs are correct and that the executions exist.
API request errors: Network issues or authentication failures when calling the n8n API will cause errors. Check API credentials and network connectivity.
Links and References
This summary is based solely on static analysis of the provided source code and property definitions.