Execution errors

Execution errors happen when a pattern fails during a run. The execution log is your primary tool for diagnosing these issues — it shows a node-by-node record of what happened, including timestamps, output values, and error messages.

Pattern fails with no error message

Symptom

The execution status shows Failed, but the execution log does not contain an error message. The pattern appears to stop at a node without explanation.

Cause

The pattern encountered an unhandled error that was not caught by a Try / Catch node and no On Error handler exists. Some errors — particularly type mismatches or null reference errors — may not produce a descriptive message in the log if there is no error handler to capture them.

Solution

1. Add an On Error node to your pattern. This is a global error handler that fires when any unhandled error occurs. Wire it to a Log node to capture the error details.

2. For more targeted error handling, wrap the suspect section of your pattern in a Try / Catch node. The Catch branch receives an Error object with message and type fields.

3. Run a test from the editor and check the console for the captured error message. The error details tell you which node failed and why.

See the Handle errors guide for detailed instructions on using On Error and Try / Catch.

Node receives wrong data type

Symptom

A node produces unexpected output, or a downstream node fails because it received the wrong type of data. For example, a Math node receives a String instead of a Number, or a Get Property node receives a String instead of an Object.

Cause

The wire connecting two nodes carries a data type that does not match what the receiving node expects. This typically happens when:

• A JSON response is not parsed, so the node receives a raw String instead of an Object
• A property extraction returns the wrong type (for example, a numeric field stored as a String)
• A wire connects pins of incompatible types

Solution

1. Open the pattern in the editor and select the failing node. Check the Inspector Panel to see what type each input pin expects.

2. Trace the wire back to the source node. Check what type that node produces on its output pin.

3. If the types do not match, add a type conversion node between them. Use To Number, To String, JSON Parse, or JSON Stringify as appropriate.

4. If the source is an HTTP Request node, make sure you parse the response body with a JSON Parse node before extracting properties. HTTP responses arrive as raw strings.

Execution times out

Symptom

The execution status shows Timeout. The execution log shows the pattern started but did not complete within the allowed time.

Cause

The pattern exceeds the maximum execution time. Common reasons include:

• An HTTP Request node calls a slow or unresponsive external API
• The pattern processes a very large collection in a loop
• A downstream service takes too long to respond

Solution

1. Identify the slow node. Check the execution log for the last node that ran successfully. The next node in the execution flow is likely the bottleneck.

2. Add timeouts to HTTP requests. If an HTTP Request node calls a slow API, set a timeout on the node so it fails fast instead of waiting indefinitely.

3. Break large work into sub-patterns. If the pattern processes a large collection, split the work across multiple pattern runs using Call Pattern. Each call gets its own execution time budget.

4. Use Respond To Webhook early. If the pattern is triggered by a webhook, use Respond To Webhook near the start of the flow to acknowledge the request immediately. The caller does not time out, and the pattern continues processing.

5. Optimize loops. If a For Each node iterates over a large collection, consider using For Each Parallel to process items concurrently instead of sequentially.

Variable has unexpected value

Symptom

A variable contains a value you did not expect. It may be null, stale from a previous node, or a different value than what you set earlier in the flow.

Cause

Variables in DRAGOPS are scoped to a single execution. They do not persist across runs. Within a single execution, the value depends on execution order — which follows the wire connections from node to node.

Common causes of unexpected values:

• The Set Variable node runs after the node that reads the variable, due to wire ordering
• A branch in the execution flow sets the variable in one path but not another
• The variable is read inside a loop but set outside it, so it holds the value from before the loop started

Solution

1. Trace the execution order. Follow the execution wires (white wires) from the trigger node through to the node that reads the variable. Make sure the Set Variable node runs before the Get Variable node in every execution path.

2. Check branch coverage. If your pattern uses Branch or Switch nodes, make sure every path sets the variable before it is read. If a branch does not set the variable, it retains its previous value (or null if never set).

3. Add logging. Place a Log node immediately after the Set Variable node and another immediately before the Get Variable node. Run a test and compare the logged values to confirm the variable changes as expected.

See the Use variables guide for more on variable scoping and execution order.

Pure node not evaluating

Symptom

A pure node (a node without execution pins, such as a math operation or string format) does not produce output. Downstream nodes receive null or no data.

Cause

Pure nodes only evaluate when their output is needed by another node. If no downstream node reads the pure node's output pin, the pure node does not execute. This is by design — pure nodes use lazy evaluation for efficiency.

Solution

1. Make sure the pure node's output pin is wired to a downstream node that actually uses the value. If the output is not connected to anything, the pure node has no reason to evaluate.

2. If you want to see the output for debugging, wire the pure node's output to a Log node. This forces evaluation and shows the result in the console.

Loop runs forever

Symptom

The execution does not complete. The execution log shows the same nodes running repeatedly. Eventually the execution times out.

Cause

A While loop or Do While loop has an exit condition that never becomes true. The loop continues indefinitely until the execution hits the timeout limit.

Solution

1. Check the exit condition. Open the While or Do While node and inspect the condition pin. Make sure the condition is wired to a value that actually changes during each iteration.

2. Replace with For Each. If you are iterating over a collection, use a For Each node instead of a While loop. For Each iterates over a finite collection and always terminates when the collection is exhausted.

3. Add a counter guard. If you must use a While loop, add a counter variable that increments on each iteration. Add a second condition that breaks the loop after a maximum number of iterations, even if the primary condition has not been met.

4. Log inside the loop. Add a Log node inside the loop body to see what the condition value is on each iteration. This reveals whether the condition is changing as expected or staying constant.

Dead letter executions

Symptom

The execution status shows Dead letter. The execution log shows the pattern attempted to run but failed, and all retry attempts are exhausted.

Cause

The pattern failed on every retry attempt. DRAGOPS automatically retries failed executions a limited number of times with exponential backoff. When all retries are exhausted, the execution is moved to the dead letter state.

Common root causes include:

• A persistent external API outage (the service the pattern calls is down)
• A bug in the pattern logic that fails on every run with the same input data
• Invalid or corrupted trigger data that causes the same error repeatedly

Solution

1. Check the execution log. Open the dead letter execution and read the error message from the final attempt. This tells you what failed.

2. Fix the root cause. If the error is a pattern logic bug, fix the pattern, redeploy, and test with the same input data. If the error is an external service outage, wait for the service to recover.

3. Add error handling. Wrap the failing section in a Try / Catch node with a Retry node for transient failures. This gives your pattern control over retry logic instead of relying on the system-level retries.

4. Test before redeploying. Use the editor to run a test with the same input data that caused the failure. Verify the pattern succeeds before redeploying.

Related

• Executions -- execution lifecycle, statuses, and logs
• Handle errors -- Try / Catch, Retry, On Error, and Throw Error
• Test and debug -- run tests, pin data, and capture live payloads
• Variables -- variable scoping and execution order
• Webhook issues -- if the trigger itself is the problem