Fail

Arrêter l'exécution du workflow avec une erreur personnalisée

À quoi sert ce node ?

Le node Fail arrête l’exécution du workflow et affiche un message d’erreur personnalisé. Utilisez-le pour valider des données, appliquer des règles métier ou gérer proprement des situations d’erreur.

Usages courants :

• Valider les données requises
• Appliquer des règles métier
• Gérer les erreurs attendues
• Fournir des messages d’erreur clairs

Configuration rapide

Configuration

Champs obligatoires

"Aucune URL fournie. Veuillez saisir une URL valide à scraper."

"Réponse API invalide : {{status}}. Vérifiez les identifiants API."

"Contenu trop court ({{wordCount}} mots). Minimum : 500 mots."

Sortie

Lorsqu’il est déclenché, le workflow s’arrête et renvoie :

{
  "status": "failed",
  "error": {
    "message": "Aucune URL fournie. Veuillez saisir une URL valide.",
    "code": "VALIDATION_ERROR",
    "node": "Fail_0",
    "timestamp": "2024-01-15T10:30:00Z"
  }
}

Exemples

Validation des données

Valider une entrée requise :

graph LR
    A[Input] --> B{URL fournie ?}
    B -->|Oui| C[Continue]
    B -->|Non| D[Fail: Pas d'URL]

Message d’erreur :

"L'URL est requise mais n'a pas été fournie. 
Veuillez saisir une URL valide pour continuer."

Application de règles métier

Imposer une longueur minimale de contenu :

graph LR
    A[Content] --> B{Nb mots >= 500 ?}
    B -->|Oui| C[Publish]
    B -->|Non| D[Fail: Trop court]

Message d’erreur :

"Le contenu est trop court ({{wordCount}} mots). 
Minimum requis : 500 mots. 
Veuillez développer le contenu avant publication."

Gestion des erreurs API

Gérer les échecs d’appel API :

graph LR
    A[API Call] --> B{Status 200 ?}
    B -->|Oui| C[Process]
    B -->|Non| D[Fail: Erreur API]

Message d’erreur :

"La requête API a échoué avec le statut {{HTTP_0.status}}.
Réponse : {{HTTP_0.body.error}}
Vérifiez vos identifiants API et réessayez."

Protection contre les limites de débit

Arrêter avant d’atteindre les limites :

graph LR
    A[Check Usage] --> B{Sous la limite ?}
    B -->|Oui| C[Continue]
    B -->|Non| D[Fail: Limite atteinte]

Message d’erreur :

"Limite de débit API atteinte ({{usage}}/{{limit}} appels).
Veuillez attendre {{resetTime}} avant de relancer."

Bonnes pratiques

Rédiger des messages d’erreur utiles

Inclure du contexte pour aider l’utilisateur à corriger le problème :

❌ "Une erreur s'est produite"

✅ "Échec du scraping de l'URL : {{url}}. 
   La page a renvoyé une erreur 403 Forbidden. 
   Cela signifie généralement que le site bloque les requêtes automatisées.
   Essayez une autre URL ou ajoutez un délai entre les requêtes."

Inclure les valeurs pertinentes

Afficher les données réelles à l’origine de l’échec :

"Validation du score échouée.
 Reçu : {{score}}
 Attendu : >= 0 et <= 100
 Vérifiez la logique de notation."

Échouer tôt

Valider les entrées au début :

graph LR
    A[Start] --> B{Entrée valide ?}
    B -->|Non| C[Fail early]
    B -->|Oui| D[Do expensive work]

Éviter de traiter des données pour échouer à la fin.

Utiliser des codes d’erreur cohérents

Définir un ensemble standard de codes d’erreur :

Envisager des alternatives

Avant d’utiliser Fail, envisager :

• Conditional : Orienter vers un autre chemin
• Valeurs par défaut : Utiliser des replis pour les données manquantes
• Logique de nouvelle tentative : Réessayer en cas d’échecs temporaires

Modèles courants

Validation au démarrage

graph LR
    A[Input] --> B{Valide ?}
    B -->|Non| C[Fail]
    B -->|Oui| D[Process]
    D --> E[Output]

Plusieurs contrôles de validation

graph LR
    A[Input] --> B{URL présente ?}
    B -->|Non| F[Fail: URL manquante]
    B -->|Oui| C{Format valide ?}
    C -->|Non| G[Fail: Format invalide]
    C -->|Oui| D{Accessible ?}
    D -->|Non| H[Fail: Inaccessible]
    D -->|Oui| E[Process]

Dégradation gracieuse

graph LR
    A[Try Primary] --> B{Réussi ?}
    B -->|Oui| C[Use Primary]
    B -->|Non| D[Try Fallback]
    D --> E{Réussi ?}
    E -->|Oui| F[Use Fallback]
    E -->|Non| G[Fail: Toutes les options épuisées]

Quand ne pas utiliser Fail

Ne pas échouer pour des cas attendus

Si « aucune donnée » est un résultat valide :

❌ Fail : "Aucun résultat trouvé"
✅ Conditional → Gérer les résultats vides proprement

Ne pas utiliser Fail dans les boucles

Un élément en erreur ne doit pas tout arrêter :

❌ Loop → Un élément échoue → Tout le workflow s'arrête
✅ Loop → Un élément échoue → Logger l'erreur → Passer au suivant

Ne pas échouer sans contexte

Toujours expliquer ce qui s’est mal passé :

❌ Fail : "Erreur"
✅ Fail : "Connexion à la base échouée après 3 tentatives. 
         Vérifiez les identifiants dans Paramètres → Intégrations."

Nodes associés