Salut @ricardo_balako
L’erreur que tu rencontres, « Cannot read properties of undefined (reading ‘execute’) », est un symptôme classique d’une panne de communication en mode queue de n8n. Puisque ton workflow fonctionne correctement dans l’éditeur mais échoue en production, le problème ne vient presque certainement pas de la logique de ton workflow lui-même, mais plutôt de la façon dont ton environnement distribué traite le job. En mode queue, l’instance principale envoie une tâche à un processus worker séparé, et si ce worker ne peut pas initialiser correctement le nœud requis, il crash avant même de pouvoir commencer l’exécution.
La cause la plus courante est un décalage de version entre ton instance principale et ton instance worker. Même si les deux semblent exécuter la dernière version, des différences subtiles dans les images Docker sous-jacentes peuvent les empêcher de communiquer correctement. Il est essentiel de s’assurer que les deux services utilisent explicitement exactement le même tag d’image et que tu effectues un redéploiement complet des deux composants simultanément pour t’assurer qu’ils sont synchronisés.
Un autre facteur critique est la cohérence de tes variables d’environnement dans toute ton infrastructure. Tes services principal et worker doivent partager exactement la même configuration, notamment en ce qui concerne la clé de chiffrement, les détails de connexion à la base de données et les paramètres Redis. Si le worker n’a pas la bonne configuration, il peut échouer à s’authentifier auprès de ta base de données ou de Redis, ce qui provoque l’erreur « undefined » quand il essaie de récupérer les données du workflow dont il a besoin pour démarrer le job.
Tu devrais aussi vérifier que ton service worker est configuré pour s’exécuter spécifiquement en tant que processus worker. Dans ta configuration Easypanel, confirme que la commande de ton conteneur worker est définie sur worker (par exemple, n8n worker). De plus, définir la variable d’environnement N8N_REINSTALL_MISSING_PACKAGES=true sur ton worker est une bonne pratique, car elle garantit que le worker dispose de toutes les dépendances nécessaires, comme celles requises par le nœud AI Agent, qui pourraient manquer dans un environnement worker vierge.
Le fait que l’erreur pointe vers bull (la bibliothèque de gestion de queue) confirme que la défaillance se produit au niveau de l’infrastructure. La meilleure façon de résoudre ce problème est d’ignorer les logs n8n principaux et de te concentrer exclusivement sur les logs du conteneur worker au moment exact où tu soumets le formulaire. Ces logs spécifiques au worker fourniront souvent la raison précise—comme un timeout de connexion ou une dépendance manquante—pour laquelle le job n’a pas pu s’initialiser.
Si tu as vérifié la version, la configuration et les logs et que le problème persiste, tu pourrais vouloir tester en définissant EXECUTIONS_PROCESS=main sur ton instance principale comme étape de diagnostic temporaire. Bien que cela contourne l’infrastructure worker, cela confirmera si le problème est strictement lié au système de queue. Si le workflow fonctionne correctement dans ce mode, cela confirme que ton problème est isolé à l’interaction entre ton instance n8n principale et les processus worker.