Gestion des erreurs

Gestion des erreurs par nœud dans Flux qui acheminent les défaillances de nœud vers un chemin distinct et exposent les détails des erreurs via des variables.

De quoi il s'agit

La gestion des erreurs dans Flux 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 une gestion des erreurs pour acheminer les échecs vers un chemin distinct où vous inspectez et répondez à l'erreur.

Mode de fonctionnement

Chaque nœud qui prend en charge la gestion des erreurs dispose d'une gestion des erreurs - un connecteur de sortie en bas à droite du nœud qui s'active lorsque le nœud échoue. Tous les nœuds ne prennent pas en charge la gestion des erreurs; seules celles avec l'indicateur supportsErrorHandling exposent une gestion d'erreur.

Lorsqu'un nœud avec une gestion des erreurs connectée échoue, l'exécution est redirigé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 gestion des erreurs connectée é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 requête HTTP

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

Configuration des gestions d'erreur

Une gestion des erreurs est connectée en connectant le connecteur de gestion des erreurs du nœud (angle inférieur droit) à un autre nœud du canevas. Un nœud sans connecteur de gestion des erreurs ne prend pas en charge la gestion des erreurs. Par conséquent, tout échec arrête le processus.

Objet d'erreur

Lorsqu'une gestion des erreurs est connectée et que le nœud échoue, les détails de l'erreur sont disponibles sous la forme $vars.<nodeName>.error. Cet objet comporte 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 ne va pas. Utilisez cette option pour consigner ou afficher les informations sur les erreurs.

Détail

Une description technique détaillée de la panne, y compris les traçages de pile ou les informations spécifiques au service lorsqu'elles sont disponibles.

Catégorie

La catégorie d'erreur, regroupant des types d'erreur liés.

statut

Le code de statut HTTP associé à l’erreur. Renseigné 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 sur le chemin de réussite renvoie un élément indéfini.

Exemple pratique

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

Un nœud de requête HTTP est placé sur le canevas et configuré avec l'URL cible. Sa gestion des erreurs est connectée à 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 requête HTTP réussit, l’exécution suit le chemin de réussite et le nœud Script est ignoré. Lorsque la demande échoue (après toutes les nouvelles tentatives configurées), l'exécution est redirigée vers le nœud Script, qui reçoit l'objet d'erreur complet.

Modèles

Il s'agit d'approches courantes pour gérer, journaliser, réessayer et escalader les 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 au niveau de $vars.<node>.error.

Enregistrer et continuer

Ce modèle correspond aux opérations non critiques dans lesquelles 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 journalise l'erreur, puis rejoint le chemin principal pour que l'exécution se poursuit.

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

Réessayer avec limite

Ce modèle correspond aux défaillances temporaires probables telles que les délais d'expiration du réseau, les limites de débit ou les interruptions temporaires du service. Pour le nœud de requête HTTP , le nombre de nouvelles tentatives intégré tente à nouveau de lancer la requête avant de déclencher la gestion des erreurs, et seul l'échec final est redirigé vers le chemin d'erreur. Les paramètres de nouvelle tentative appartiennent uniquement aux opérations idempotentes.

Alerter et terminer

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 requête HTTP ou un nœud d'intégration), puis un nœud Terminer avec le statut Failed et un message descriptif tel que $vars.step1.error.message termine le workflow.

Valeur de secours

Ce modèle correspond aux opérations qui peuvent échouer, mais possèdent 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

• Autorisation silencieuse des erreurs - Les erreurs sur le chemin d'erreur doivent toujours être journalisées, même lorsque le workflow se poursuit. Les défaillances silencieuses sont difficiles à diagnostiquer ultérieurement.
• Réessai 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 sont réessayées. Les paramètres de nouvelle tentative appartiennent uniquement aux opérations qui peuvent s’exécuter plusieurs fois sans créer de doublons.
• Laisser les gestions d'erreurs non connectées - Un nœud dont la gestion des erreurs n'est pas connectée échoue l'ensemble du processus en cas d'erreur. Les workflows qui doivent passer par 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
• Le canevas — vue d'ensemble de l'espace de travail, y compris le panneau d'exécution
• Variables et flux de données - comment les données sont transmises entre les nœuds à l'aide de $vars
• Déboguer efficacement — conseils pour inspecter les erreurs en mode Debug