mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 21:41:42 +02:00
fe04edb7bf
- Nouveaux fichiers : 10_product_patterns_valides.md, 10_conventions_redaction.md - Templates n8n déplacés vers 70_templates/ (workflow + intégration) - Contenu 10_n8n_README.md absorbé dans les fichiers dédiés patterns/risques - Suppression des stubs 10_n8n_README.md, 20_worklows_README.md, 30_integrations_README.md - Index, _AI_INSTRUCTIONS, 95_a_capitaliser et post-bmad-install.sh mis à jour Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2.2 KiB
2.2 KiB
Nodes n8n à risque / vigilance
Ce fichier recense les nodes, fonctionnalités ou patterns n8n sensibles, c’est-à-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 retournerundefinedsilencieusement - Comportements implicites des nodes : toujours tester les cas limites (null, tableau vide, erreur HTTP)
Règles d’utilisation
- 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 c’est lié à une version : on note la version.
IF Node
Risques
- Comparaisons ambiguës entre
null,undefined,""etfalse - Résultats surprenants si les types ne sont pas normalisés
Symptômes
- Branche IF “inversée” par rapport à l’intuition
- 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 à l’
executionIdsi on fait de l’agré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 qu’il 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