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

La gestion des erreurs dans Flow est un mécanisme par nœud qui vous permet de contrôler ce qui se passe lorsqu'un nœud échoue pendant l'exécution. Par défaut, un nœud échoué arrête l'ensemble du processus. Vous pouvez remplacer cela en connectant un gestionnaire d'erreurs pour acheminer les échecs vers un chemin distinct où vous inspectez et répondez à l'erreur.

Mode de fonctionnement

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. 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.

Configuration des gestionnaires d'erreurs

Un gestionnaire d'erreurs est câblé en connectant le connecteur de gestionnaire d'erreurs du nœud (coin inférieur droit) à un autre nœud de la zone de dessin. Un nœud sans connecteur de gestionnaire d'erreurs ne prend pas en charge la gestion des erreurs, de sorte que tout échec arrête le processus.

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

Cet exemple utilise un nœud de demande HTTP pour appeler une API externe, avec un nœud Script sur le chemin d'erreur qui enregistre l'échec.

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.

Enregistrer et continuer

Ce modèle s'adapte aux opérations non critiques où le workflow doit se poursuivre même si une étape échoue. La gestion des erreurs du nœud se connecte à un nœud Script qui enregistre l'erreur, puis rejoint le chemin principal afin que l'exécution se poursuive.

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

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