Comportement observé
Tous les retours HTTP 200 en amont étaient acheminés comme s’ils étaient acceptés, même lorsque le corps de la réponse JSON retournait needs_input ou failed.
EXEMPLE DE DOSSIER DE RÉPARATION
Exemple de dossier de réparation · DEMO-001
Exemple : réparer un parcours n8n défaillant de routage des prospects
Le projet pilote à 99 $ CA (CAD 99) comprend le diagnostic, un correctif contrôlé s’il y a lieu, des éléments de validation, des notes de retour en arrière et une liste de vérification en préproduction.
01 / Problème
Une réponse HTTP 200 envoyait le flux de travail dans le mauvais parcours.
Ce que la réparation doit faire
La logique corrigée doit suivre le résultat dans le corps de la réponse, relever les identifiants de prospect manquants, s’arrêter de façon sécuritaire devant un état inconnu et conserver l’identifiant d’événement entrant pour les vérifications de rejeu du client en préproduction.
02 / Diagnostic
Le flux vérifiait la livraison, et non le résultat dans la réponse.
Le flux traitait la réussite au niveau HTTP comme un prospect accepté sans lire le résultat opérationnel dans body.status. Un deuxième mappage attendait seulement lead_id; les charges utiles utilisant leadId perdaient donc leur identifiant avant l’étape de réponse.
avant : accepted = response.statusCode === 200
après : outcome = normalizeStatus(response.body?.status)
leadId = input.leadId ?? input.lead_id ?? null
03 / Correctif sécuritaire
Lire d’abord le résultat, normaliser l’identifiant et échouer de façon sécuritaire.
- Normaliser
leadIdetlead_iddans un seul champ interne avant tout embranchement. - Lire d’abord le corps de la réponse JSON; mapper uniquement
accepted,needs_inputetfailed. - Diriger les identifiants manquants vers une réponse de validation et les états inconnus vers une branche d’échec fermée.
- Conserver l’identifiant d’événement entrant pour la comparaison des rejeux par le client. La suppression des doublons n’est ni mise en œuvre ni revendiquée dans cet exemple.
04 / Validation
Six cas fictifs vérifient la logique de décision corrigée.
| Cas d’essai | Variation d’entrée | Branche attendue | Résultat observé |
|---|---|---|---|
| F-01 | lead_id + accepted | accepted | RÉUSSI · LOGIQUE ISOLÉE |
| F-02 | leadId + accepted | accepted | RÉUSSI · LOGIQUE ISOLÉE |
| F-03 | HTTP 200 + needs_input | needs_input | RÉUSSI · LOGIQUE ISOLÉE |
| F-04 | HTTP 200 + failed | failed | RÉUSSI · LOGIQUE ISOLÉE |
| F-05 | identifiant de prospect manquant | validation_error | RÉUSSI · LOGIQUE ISOLÉE |
| F-06 | état inconnu dans le corps | failed_closed | RÉUSSI · LOGIQUE ISOLÉE |
05 / Plan de retour en arrière
Tester en préproduction, avec l’original intact prêt à être réactivé.
Liste de vérification en préproduction
Importer le fichier JSON corrigé dans un projet en préproduction, reconnecter les identifiants d’accès appartenant au client, rejouer F-01 à F-06 et confirmer que les écritures en aval utilisent l’identifiant de prospect normalisé. Les réussites hors ligne ne remplacent pas cette vérification d’exécution dans n8n.
Étapes de retour en arrière
Désactiver le flux de travail corrigé, réactiver l’exportation originale intacte, puis effectuer un rejeu seulement après que le client a vérifié que l’identifiant d’événement est absent du journal de destination. Aucune déduplication automatique n’est comprise.