J’exécute n8n en Mode File d’attente (Redis + Worker + Database) et j’ai rencontré un problème où je ne peux pas déterminer de manière fiable le dernier nœud exécuté quand Redis devient indisponible.
Décrivez le problème/l’erreur/la question
Pendant l’exécution du workflow, si Redis se déconnecte ou redémarre, le comportement suivant se produit :
L’exécution reste en état d’exécution dans la base de données
Aucune progression d’exécution n’est visible dans l’interface utilisateur
Après la récupération de Redis, l’exécution ne reprend pas ou ne met pas à jour la progression
Après le redémarrage de l’instance n8n principale, l’état d’exécution est mis à jour sur plantage
Cependant, l’interface utilisateur et les données d’exécution ne montrent pas clairement à quel nœud le workflow s’est arrêté
Informations sur votre configuration n8n
- Version n8n : 2.11.4
- Base de données (par défaut : SQLite) : pgsql
- Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : Docker
- Système d’exploitation :
Question
- Y a-t-il une méthode officielle ou recommandée pour déterminer le dernier nœud complété avec succès dans ce scénario ?
Bonjour @halouprogramer
Votre configuration n8n utilise Redis comme « messager » pour coordonner le travail entre le système principal et les workers. Quand Redis se déconnecte, le messager disparaît, ce qui signifie que le système principal ne reçoit jamais le signal indiquant qu’une tâche est terminée. Cela laisse la tâche bloquée dans un état « en cours d’exécution ». Quand vous redémarrez le système, n8n remarque que la tâche ne s’est jamais officiellement terminée et la marque comme « plantée » pour faire un nettoyage.
Bien que la tâche soit étiquetée comme « plantée », n8n enregistre généralement les résultats de chaque étape individuelle (nœud) dans votre base de données au fur et à mesure. Le problème est que l’interface utilisateur de n8n n’est pas conçue pour afficher cette progression partielle pour les exécutions plantées. C’est pourquoi l’interface semble vide ou ne met pas en évidence l’endroit où le workflow s’est arrêté, même si les données existent réellement.
Pour découvrir exactement quel nœud a terminé en dernier, vous devez contourner l’interface utilisateur et regarder directement votre base de données PostgreSQL. En recherchant l’ID d’exécution spécifique dans les tables de la base de données, vous pouvez voir les données brutes de cette exécution. Le dernier nœud qui a enregistré avec succès sa sortie dans la base de données est celui où le workflow s’est arrêté.
SELECT data
FROM execution_entity
WHERE id = YOUR_EXECUTION_ID;
Note : Exécutez la requête suivante sur votre instance Postgres (remplacez YOUR_EXECUTION_ID par l’ID réel)
Pour éviter que cela ne se reproduise à l’avenir, vous pouvez ajuster quelques paramètres pour rendre votre système plus résilient. Augmenter le délai d’expiration de Redis donne à n8n plus de temps pour se rétablir après des défaillances réseau brèves, et définir un « Execution Timeout » maximal garantit que les tâches bloquées sont automatiquement fermées au lieu de rester indéfiniment dans un état « en cours d’exécution ».
Bienvenue dans la communauté @halouprogramer !
En mode file d’attente, ce que tu vois est malheureusement attendu : une fois que Redis s’arrête en cours d’exécution, l’instance principale ne reçoit jamais de signal clean « j’ai terminé » du worker, donc l’exécution reste en « en cours » jusqu’à ce que quelque chose la nettoie, et quand c’est nettoyé, elle est marquée comme « plantée » sans contexte au niveau du nœud dans l’interface.
Si tu as vraiment besoin de savoir « où s’est-ce arrêté ? », tu as essentiellement deux options :
-
À partir de maintenant : active « Save Execution Progress » pour ce workflow, pour que n8n écrive les données après chaque nœud et tu puisses voir le dernier nœud complété même quand le statut final est plantée.
-
Maintenant / rétroactivement : interroge ta base de données Postgres execution_entity pour l’ID d’exécution spécifique et inspecte directement la charge utile data – ce JSON brut contient généralement le dernier nœud qui a réussi à persister sa sortie, même si l’interface ne l’affiche pas pour les exécutions plantées.
Au-delà de cela, le seul vrai correctif est de maintenir Redis stable (timeouts, reconnexion, côté infrastructure), car tant que le « messager » peut disparaître aléatoirement, n8n n’a aucun moyen fiable de fermer la boucle et de marquer l’exécution avec un état final exact.
Je traiterais cela comme un problème d’observabilité et de conception de la récupération, et non pas simplement comme un problème Redis. Pour les flux de travail en production, ajoutez une journalisation des points de contrôle autour des nœuds critiques afin de pouvoir déterminer ce qui a été complété même si l’interface d’exécution indique seulement un plantage. Examinez ensuite le comportement de redémarrage de la file d’attente/du worker et la persistance de Redis, car sans points de contrôle, le flux de travail peut échouer de la pire manière possible : à moitié terminé sans point de reprise évident.