Administración de errores

Controladores de error por nodo en Flujo que enrutan los fallos de nodo a una ruta independiente y exponen los detalles del error a través de variables.

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 turning on error handling for the node and connecting its 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 handling tab in its properties panel. The Enable error handling toggle on that tab adds an error handle to the node: a second output connector labeled Error, below the main output handle, that activates when the node fails. The majority of nodes support error handling.

Cuando falla un nodo con un identificador de error conectado, la ejecución enruta a la ruta de error en lugar de detener el proceso. Los detalles del error están disponibles como una variable que puedes leer en los nodos posteriores.

Cuando falla un nodo sin un controlador de errores conectado, todo el proceso falla inmediatamente. El error aparece en el panel de ejecución en la pestaña Incidentes .

Reintentos de solicitud HTTP

El nodo de solicitud HTTP admite reintentos configurables. Cuando se configuran los reintentos, el nodo intenta la solicitud el número de veces especificado antes de desencadenar el controlador de error. Si todos los reintentos fallan y se conecta un controlador de errores, la ejecución enruta a la ruta de error. Si no se conecta ningún controlador de errores, el proceso falla.

Errors from the vendor system

Connector nodes and HTTP requests that go through Integration Service fail when the vendor system answers with an error status, meaning anything other than 2xx. The error has the code IntSvcVendorRequestFailed (102021) and a message in the form Received failure from vendor system on API - <url>: HTTP Status: <code> - <vendor message>. The error's status is the vendor's status, so you can branch on it on the error path. A 4xx status isn't retried, and other statuses are.

Configurar controladores de error

Turning on Enable error handling in the Error handling tab of the properties panel adds the error handle to the node. Connecting the Error handle to another node on the canvas wires the error path. A node without an Error handling tab does not support error handling, so any failure stops the process.

El objeto de error

Cuando se conecta un controlador de error y el nodo falla, los detalles del error están disponibles como $vars.<nodeName>.error. Este objeto tiene los siguientes campos:

code

Un código de error legible por máquina que identifica el tipo de fallo.

Mensaje

Una descripción legible por humanos de lo que salió mal. Utilízalo para registrar o mostrar información de error.

Detalles

Una descripción técnica detallada del fallo, incluidos los seguimientos de pila o información específica del servicio cuando esté disponible.

Categoría

La categoría de error, que agrupa los tipos de error relacionados.

estado

El código de estado HTTP asociado con el error. Se rellena para fallos relacionados con HTTP (por ejemplo, 404 o 500).

El objeto de error solo está disponible en la ruta de error. Acceder $vars.<nodeName>.error en la ruta de éxito devuelve indefinido.

Ejemplo práctico

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

Se coloca un nodo de solicitud HTTP en el lienzo y se configura con la URL de destino. Su manipulador de errores está conectado a un nodo de Script . El nodo Script lee el objeto de error de la siguiente manera:

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

Cuando la solicitud HTTP tiene éxito, la ejecución sigue la ruta de éxito y se omite el nodo Script. Cuando la solicitud falla (después de cualquier reintento configurado), la ejecución se enruta al nodo Script, que recibe el objeto de error completo.

Patrones

Estos son enfoques comunes para gestionar, registrar, reintentar y escalar errores. Todos se basan en el controlador de error por nodo descrito anteriormente: un controlador de error conectado enruta los fallos a una ruta independiente, donde el objeto de error está disponible en $vars.<node>.error.

Return error details 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 returns the error message, then rejoins the main path so execution continues.

// Script node on the error path
return {
  message: "Error raised: " + $vars.step1.error.message,
  result: null // downstream nodes handle a null result
};

Reintentar con límite

Este patrón se ajusta a fallos transitorios probables, como tiempos de espera de la red, límites de tasa o interrupciones temporales del servicio. Para el nodo de solicitud HTTP , el recuento de reintentos integrado vuelve a intentar la solicitud antes de desencadenar el controlador de error, y solo el fallo final enruta a la ruta de error. La configuración de reintento pertenece solo a operaciones idempotentes.

Alertar y finalizar

Este patrón se ajusta a errores irrecuperables que requieren atención humana. En la ruta de error, se envía una notificación (a través de una solicitud HTTP o un nodo de integración), luego un nodo Terminar con estado Failed y un mensaje descriptivo como $vars.step1.error.message finaliza el flujo de trabajo.

Valor alternativo

Este patrón se ajusta a las operaciones que pueden fallar pero tienen un valor predeterminado seguro que permite que el flujo de trabajo continúe de forma significativa. En la ruta de error, un nodo de Script establece la salida esperada en un valor predeterminado y luego se vuelve a unir a la ruta principal como si la operación se hubiera realizado correctamente.

Errores comunes

• Tragar errores de forma silenciosa : los errores en la ruta de error siempre deben registrarse, incluso cuando el flujo de trabajo continúa. Los fallos silenciosos son difíciles de diagnosticar más tarde.
• Reintentar operaciones no idempotentes : las operaciones con efectos secundarios (escribir datos, enviar un mensaje) pueden producir duplicados si se reintentan. La configuración de reintento pertenece solo a operaciones que pueden ejecutarse más de una vez sin crear duplicados.
• Dejar los controladores de error desconectados : un nodo cuyo controlador de error no está conectado falla todo el proceso en caso de error. Los flujos de trabajo que deben continuar más allá de un error necesitan una ruta de error conectada.

Páginas relacionadas

• Gestionar errores : tarea paso a paso: crear una ruta de error de extremo a extremo
• El lienzo : descripción general del espacio de trabajo, incluido el panel de ejecución
• Variables y flujo de datos : cómo pasan los datos entre nodos utilizando $vars
• Depurar de forma efectiva : consejos para inspeccionar errores en modo de depuración