Administración de errores

Qué es

Error handling in Flow is a per-node mechanism that lets you control what happens when a node fails during execution. By default, a failed node stops the entire process. You can override this by connecting an error handle to route failures to a separate path where you inspect and respond to the error.

Cómo funciona

Every node that supports error handling has an error handle — an output connector on the bottom-right of the node that activates when the node fails. Not all nodes support error handling; only those with the supportsErrorHandling flag expose an error handle.

When a node with a connected error handle fails, execution routes to the error path instead of stopping the process. The error details become available as a variable you can read in downstream nodes.

When a node without a connected error handle fails, the entire process fails immediately. The error surfaces in the execution panel under the Incidents tab.

HTTP Request retries

The HTTP Request node supports configurable retries. When retries are configured, the node attempts the request the specified number of times before triggering the error handle. If all retries fail and an error handle is connected, execution routes to the error path. If no error handle is connected, the process fails.

Configuring error handles

An error handle is wired by connecting the node's error handle connector (bottom-right corner) to another node on the canvas. A node without an error handle connector does not support error handling, so any failure stops the process.

The error object

When an error handle is connected and the node fails, the error details are available as $vars.<nodeName>.error. This object has the following fields:

code

A machine-readable error code identifying the type of failure.

Mensaje

A human-readable description of what went wrong. Use this for logging or displaying error information.

detail

A detailed technical description of the failure, including stack traces or service-specific information when available.

Categoría

The error category, grouping related error types.

estado

The HTTP status code associated with the error. Populated for HTTP-related failures (for example, 404 or 500).

The error object is only available on the error path. Accessing $vars.<nodeName>.error on the success path returns undefined.

Practical example

This example uses an HTTP Request node to call an external API, with a Script node on the error path that logs the failure.

An HTTP Request node is placed on the canvas and configured with the target URL. Its error handle is connected to a Script node. The Script node reads the error object as follows:

const error = $vars.httpRequest1.error;
return {
  failed: true,
  reason: error.message,
  httpStatus: error.status,
  detail: error.detail
};

When the HTTP request succeeds, execution follows the success path and the Script node is skipped. When the request fails (after any configured retries), execution routes to the Script node, which receives the full error object.

Patterns

These are common approaches to handling, logging, retrying, and escalating errors. They all build on the per-node error handle described above: a connected error handle routes failures to a separate path, where the error object is available at $vars.<node>.error.

Log and continue

This pattern fits non-critical operations where the workflow should continue even if one step fails. The node's error handle connects to a Script node that logs the error, then rejoins the main path so execution continues.

// Script node on the error path
console.log('Non-critical step failed:', $vars.step1.error.message);
return null; // downstream nodes handle null gracefully

Retry with limit

This pattern fits likely transient failures such as network timeouts, rate limits, or temporary service outages. For the HTTP Request node, the built-in retry count re-attempts the request before triggering the error handle, and only the final failure routes to the error path. Retry settings belong only on idempotent operations.

Alert and terminate

This pattern fits unrecoverable errors that require human attention. On the error path, a notification is sent (via an HTTP Request or integration node), then a Terminate node with status Failed and a descriptive message such as $vars.step1.error.message ends the workflow.

Fallback value

This pattern fits operations that may fail but have a safe default value that allows the workflow to continue meaningfully. On the error path, a Script node sets the expected output to a default value, then rejoins the main path as if the operation had succeeded.

Common mistakes

• Swallowing errors silently — Errors on the error path should always be logged, even when the workflow continues. Silent failures are hard to diagnose later.
• Retrying non-idempotent operations — Operations with side effects (writing data, sending a message) may produce duplicates if retried. Retry settings belong only on operations that can run more than once without creating duplicates.
• Leaving error handles unconnected — A node whose error handle isn't connected fails the entire process on error. Workflows that should continue past a failure need a connected error path.

Páginas relacionadas

• Handle errors — step-by-step task: build an error path end to end
• The canvas — overview of the workspace including the execution panel
• Variables and data flow — how data passes between nodes using $vars
• Debugging effectively — tips for inspecting errors in Debug mode