The Altostrat Workflow Engine is designed to be powerful and flexible, but like any system, it has operational limits and specific behaviors it’s important to understand. Knowing these will help you build more reliable and efficient workflows.

​
Execution and Performance Limits

These limits are in place to ensure system stability and prevent accidental misuse that could lead to performance degradation or excessive costs.

​
Workflow Run Duration

A single workflow run has a maximum execution time. If a run exceeds this limit, it will be automatically terminated and marked as failed.
  • Maximum Total Duration: 1 hour.
  • Single Node Timeout: 5 minutes.
If you have a very long-running process, consider breaking it into multiple, smaller workflows linked together with the Trigger Workflow action.

​
Iterator Node Limits

The Iterator is a powerful tool for batch processing, but it has safeguards to prevent “fork bomb” scenarios where an iteration could trigger an exponential number of jobs.
  • Maximum Items: An iterator can process a maximum of 1,000 items in a single run. If the input array is larger, the step will fail.
  • Maximum Nesting Depth: You can nest Iterators within other Iterators, but only up to 5 levels deep. This prevents recursive loops from overwhelming the system.

​
Delay Node Maximum

The Delay action provides a simple way to pause a workflow, but it is intended for short-term waits.
  • Maximum Delay: A single Delay node can pause a workflow for a maximum of 15 minutes (900 seconds).
This limit is based on the underlying queueing technology. For longer-term scheduled actions, it’s better to end the workflow and have a separate scheduled workflow to handle the follow-up task.

​
Log and Run Retention

To maintain system performance, historical run and log data is not stored indefinitely in the primary database.
  • Retention Period: Workflow runs and their associated logs are kept for 90 days.
  • Archiving: After 90 days, data is moved to a long-term archive. It will no longer be visible in the main UI but may be retrievable for audit purposes upon request.

​
Behavioral Edge Cases

Understanding these specific behaviors can help you debug and design your workflows more effectively.

​
Variable Resolution in Text

The system’s variable replacement (e.g., {{ node_1.user.name }}) is very flexible, but has a specific behavior when dealing with different data types inside a larger string.
For more advanced templating capabilities, see our Liquid Templating documentation.
  • Simple Replacement ({{ ... }} only): If a field contains only a variable reference, like {{ node_1.user }}, the system will replace it with the raw data type. If node_1.user is a JSON object, the field will become that JSON object.
  • Embedded Replacement (Hello {{...}}): If a variable is part of a larger string, like "User ID is {{ node_1.id }}", the system will convert the variable’s value to a string before inserting it. If the variable contains a JSON object or array, it will be converted into its JSON string representation.

​
”Continue on Error” Path

When you enable continue_on_error for a node, its behavior changes significantly upon failure:
  • The workflow does not stop.
  • The node’s output becomes an error object (e.g., {"error": true, "message": "API returned 503"}). This error object is added to the context.
  • The workflow proceeds only down the special error path from that node. The true, false, or default success paths are ignored.
  • If no error path is connected, that branch of the workflow simply terminates without failing the entire run.

​
Iterator Failure

The Iterator action processes items in parallel. However, its error handling is atomic:
  • If any single item within the iteration fails its sub-workflow, the entire Iterator node is considered to have failed.
  • The parent workflow run will be immediately marked as failed, and processing of other items in the batch will be stopped. There is no partial success for an Iterator.

​
Circular Dependency Detection

The system actively prevents you from creating workflows that could call each other in an infinite loop.
  • On Save: When you save a workflow, the system checks all Trigger Workflow actions. If it detects a path that could lead back to the workflow being saved (e.g., A calls B, which calls C, which calls A), the save operation will be blocked with an error.
  • At Runtime: As an additional safeguard, the system tracks the “call stack” of a workflow run. If a workflow.triggered event is received for a workflow that is already in its own call stack, that trigger will be ignored to prevent a loop from starting.