Gestion des erreurs

Dans Flow, des gestionnaires d'erreurs par nœud qui redirigent les défaillances des nœuds vers un chemin distinct et fournissent les détails de l'erreur via des variables.

De quoi il s'agit

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.

Mode de fonctionnement

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.

Lorsqu'un nœud avec un gestionnaire d'erreurs connecté échoue, l'exécution est acheminée vers le chemin d'erreur au lieu d'arrêter le processus. Les détails de l'erreur deviennent disponibles sous forme de variable que vous pouvez lire dans les nœuds en aval.

Lorsqu'un nœud sans gestionnaire d'erreurs connecté échoue, l'ensemble du processus échoue immédiatement. L'erreur apparaît dans le panneau d'exécution sous l'onglet Incidents.

Nouvelles tentatives de demande HTTP

Le nœud de demande HTTP prend en charge les tentatives configurables. Lorsque les nouvelles tentatives sont configurées, le nœud tente d'effectuer la requête le nombre de fois spécifié avant de déclencher le gestionnaire d'erreurs. Si toutes les nouvelles tentatives échouent et qu'un gestionnaire d'erreurs est connecté, l'exécution est acheminée vers le chemin d'erreur. Si aucun gestionnaire d'erreurs n'est connecté, le processus échoue.

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.

Configuration des gestionnaires d'erreurs

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.

L'objet d'erreur

Lorsqu'un gestionnaire d'erreurs est connecté et que le nœud échoue, les détails de l'erreur sont disponibles sous forme de $vars.<nodeName>.error. Cet objet a les champs suivants :

code

Un code d'erreur lisible par machine identifiant le type d'échec.

Message

Une description lisible par un humain de ce qui s'est mal passé. Utilisez-la pour la journalisation ou l'affichage des informations d'erreur.

Détail

Une description technique détaillée de l'échec, y compris les traces de la pile ou des informations spécifiques au service, lorsqu'elles sont disponibles.

Catégorie

La catégorie d'erreurs, qui regroupe les types d'erreurs liés.

statut

Le code de statut HTTP associé à l'erreur. Rempli pour les échecs liés à HTTP (par exemple, 404 ou 500).

L'objet d'erreur est uniquement disponible sur le chemin d'erreur. L'accès à $vars.<nodeName>.error dans la chaîne de réussite renvoie la valeur undefined.

Exemple pratique

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.

Un nœud de demande HTTP est placé sur la zone de dessin et configuré avec l'URL cible. Son gestionnaire d'erreurs est connecté à un nœud Script. Le nœud Script lit l'objet d'erreur comme suit :

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

Lorsque la demande HTTP réussit, l'exécution suit la chaîne de réussite et le nœud Script est ignoré. Lorsque la requête échoue (après toutes les nouvelles tentatives configurées), l'exécution est acheminée vers le nœud Script, qui reçoit l'objet d'erreur complet.

Modèles

Ce sont des approches courantes de la gestion, de la journalisation, du réessai et de l'escalade des erreurs. Ils s'appuient tous sur la gestion des erreurs par nœud décrite ci-dessus : une gestion des erreurs connectée achemine les échecs vers un chemin distinct, où l'objet d'erreur est disponible sur $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
};

Nouvelle tentative avec limite

Ce modèle s'adapte aux défaillances transitoires probables telles que les délais d'attente réseau, les limites de taux ou les pannes de service temporaires. Pour le nœud de demande HTTP, le nombre de nouvelles tentatives intégré relance la requête avant de déclencher la gestion des erreurs et seul l'échec final est acheminé vers le chemin d'erreur. Les paramètres de nouvelle tentative appartiennent uniquement aux opérations idempotentes.

Alerte et résiliation

Ce modèle correspond aux erreurs irrécupérables qui nécessitent une attention humaine. Sur le chemin d'erreur, une notification est envoyée (via une demande HTTP ou un nœud d'intégration), puis un nœud Résilier avec un statut Failed et un message descriptif tel que $vars.step1.error.message met fin au workflow.

Valeur de repli

Ce modèle s'adapte aux opérations qui peuvent échouer, mais qui ont une valeur par défaut sécurisée qui permet au workflow de se poursuivre de manière significative. Sur le chemin d'erreur, un nœud Script définit la sortie attendue sur une valeur par défaut, puis rejoint le chemin principal comme si l'opération avait réussi.

Erreurs courantes

• Passer les erreurs sous silence - Les erreurs sur le chemin d'erreur doivent toujours être journalisées, même lorsque le workflow se poursuit. Les échecs silencieux sont difficiles à diagnostiquer plus tard.
• Nouvelle tentative d'opérations non idempotentes — Les opérations avec des effets secondaires (écriture de données, envoi d'un message) peuvent produire des doublons si elles font l'objet d'une nouvelle tentative. Les paramètres de nouvelle tentative appartiennent uniquement aux opérations qui peuvent s'exécuter plus d'une fois sans créer de doublons.
• Laisser les gestionnaires d'erreurs déconnectés - Un nœud dont le gestionnaire d'erreurs n'est pas connecté fait échouer l'ensemble du processus en cas d'erreur. Les workflows qui doivent se poursuivre après un échec ont besoin d'un chemin d'erreur connecté.

Pages liées

• Gérer les erreurs - tâche étape par étape : créer un chemin d'erreur de bout en bout
• La zone de dessin - vue d'ensemble du workspace, y compris le panneau d'exécution
• Variables et flux de données - comment les données passent entre les nœuds à l'aide de $vars
• Débogage efficace - conseils pour l'inspection des erreurs en mode Debug