Error handling and validation

Configure explicit retry or continue behaviour and understand what validation cannot protect you from at runtime.

Workflow failure behaviour is explicit: decide what should stop, what may retry and what can continue with an error recorded.

Default behaviour is abort, with no retry

Nodes do not retry by default. If a node throws and no alternative failure strategy applies, execution stops and the run ends in error.

Retry is opt-in per node

For supported non-trigger nodes, Enable Retry adds node-level retry behaviour. The current defaults when enabled are:

• 3 retries;

• 1,000 ms fixed interval;

• abort after retries are exhausted.

The current UI allows retry count and interval to be adjusted, but there is no exponential backoff or jitter.

Some integration write actions are marked non-retryable to avoid duplicating side effects. For those actions, the platform overrides builder retry settings.

Continue after a failed node

A node can instead continue after retries are exhausted. Downstream logic can inspect _error and _retries and branch accordingly.

There is no general fallback feature today: no fallback model, dedicated error output handle or automatic alternative path. If you need an error route, use continue plus explicit downstream logic.

A Workflow that continues past a node error still finishes with an overall error status. Continuing execution does not turn the failed run into success.

Understand a failed production run

When a published Workflow fails and Lleverage has enough deterministic evidence, the failure is classified and the notification points to the person who can most safely act next. Depending on the evidence, that can distinguish issues such as unreadable input, context limits, workflow configuration or script problems, provider or upstream failures, and aborted or timed-out execution.

For signed-in viewers, the failed-run view also leads with a short plain-language explanation: What happened and What you can do. The explanation uses the viewer's browser language where possible and keeps the raw error collapsed underneath for deeper diagnosis. When Lleverage cannot produce the explanation, the raw error remains available instead. Anonymous Workflow-app viewers currently fall back to the raw error because the explanation service requires an authenticated viewer.

Treat the classification and plain-language explanation as routing help, not a replacement for the execution evidence. Open Activity to inspect the affected run and keep the raw failure detail available when deeper debugging is needed.

If the platform cannot identify a cause safely, the failure remains unknown instead of guessing. An unknown classification does not by itself establish whether the problem is in the Workflow, an external system or Lleverage.

In-app Workflow-failure notifications are currently sent for production executions to Project Owners and Builders. Test executions do not send these notifications.

Terminal status

When several terminal conditions are present, the engine prioritises aborted/timeout, then error, paused, continue and success. A Request pause therefore produces a paused execution unless a higher-priority terminal condition has occurred.

Validation is narrower than runtime

Builder validation catches configuration omissions and selected node-specific minimums. It does not prove that expressions, third-party APIs, permissions, rate limits, live data or trigger delivery will work.

Use Monitoring to investigate failures and treat recurring errors as evidence that the implementation needs changing.