Files
_Assistant_Lead_Tech/10_n8n_risques_et_vigilance.md
MaksTinyWorkshop 75bfa3cf8e refactor: renommer 10_n8n_nodes_a_risques → 10_n8n_risques_et_vigilance
Alignement sur la convention de nommage uniforme des fichiers de risques.
Mise à jour de toutes les références (index, instructions, templates, zone tampon).
2026-03-08 19:46:58 +01:00

2.2 KiB
Raw Blame History

Nodes n8n à risque / vigilance

Ce fichier recense les nodes, fonctionnalités ou patterns n8n sensibles, cest-à-dire susceptibles de provoquer :

  • des bugs subtils,
  • des comportements inattendus,
  • des problèmes lors des upgrades.

Dernière mise à jour : 2025-12-19


Vigilance générale

  • Différences de comportement entre n8n cloud et self-hosted (certains nodes, credentials, timeouts)
  • Expressions mal évaluées : {{ $json.field }} peut retourner undefined silencieusement
  • Comportements implicites des nodes : toujours tester les cas limites (null, tableau vide, erreur HTTP)

Règles dutilisation

  • On documente uniquement des cas vus en vrai (ou très probables + signalés).
  • Chaque entrée doit dire :
    • ce qui peut mal se passer,
    • comment on le voit (symptômes),
    • comment on le maîtrise (mitigation).
  • Si cest lié à une version : on note la version.

IF Node

Risques

  • Comparaisons ambiguës entre null, undefined, "" et false
  • Résultats surprenants si les types ne sont pas normalisés

Symptômes

  • Branche IF “inversée” par rapport à lintuition
  • Cas limites qui passent en prod mais pas en test

Bonnes pratiques / mitigations

  • Normaliser les données avant comparaison (string/number/bool)
  • Tester explicitement null / undefined
  • Logguer la valeur et le type en amont si doute

Contexte technique

  • Observé : (à compléter quand tu as un cas précis)
  • n8n : (version à préciser)

staticData ($getWorkflowStaticData)

Risques

  • Persistance entre exécutions (effet mémoire non voulu)
  • Dépendance forte à lexecutionId si on fait de lagrégation
  • Sensible aux upgrades n8n (comportements qui peuvent changer)

Symptômes

  • Données “fantômes” réutilisées
  • Résultats incohérents entre exécutions
  • Branches parallèles qui sécrasent

Bonnes pratiques / mitigations

  • Toujours lier les données à executionId
  • Nettoyer/reset explicitement à chaque run
  • Documenter le pattern dès quil est utilisé
  • Préférer un stockage externe si létat devient critique (DB/Redis/etc.)

Contexte technique

  • Validé : oui (usage avancé)
  • n8n : 1.121.2 / self-hosted / docker