Décrivez le problème/l’erreur/la question
Mon pipeline est composé de plusieurs déclencheurs webhook et plusieurs déclencheurs programmés, plus environ 15 sous-workflows imbriqués (appelés via Execute Workflow).
Récemment, j’ai voulu configurer un environnement de développement. Je ne peux pas rediriger mes webhooks vers une cible de dev distincte, donc la meilleure idée que j’ai trouvée était de copier l’ensemble du pipeline et de connecter la copie au pipeline principal via un nœud IF et une variable globale dev: on/off. Quand dev est activé, chaque charge utile entrante est dupliquée et également envoyée à la copie dev via un webhook. Quand dev est désactivé, seul le prod s’exécute. L’objectif était de tester exactement les mêmes données réelles qui arrivent en prod, mais sur la copie dev, et une fois que quelque chose fonctionne là, le déplacer vers prod. C’est important car, comme je l’ai dit, j’ai environ 15 sous-workflows imbriqués, donc je veux vraiment valider les modifications sur le trafic réel avant de les promouvoir.
Après avoir connecté la copie dev à prod, j’ai commencé à rencontrer des problèmes étranges que je n’avais jamais eus auparavant :
- Certains sous-workflows qui étaient clairement publiés dans le workflow principal ont commencé à lancer des erreurs comme « sous-workflow non publié ». Cela n’avait aucun sens pour moi, ils étaient publiés.
- J’ai commencé à avoir des problèmes de conditions de concurrence sur pratiquement tous les nœuds qui touchent les Tables de données n8n / la DB intégrée.
Supprimer le pipeline dev a fait disparaître tout cela immédiatement.
J’ai donc deux questions :
- Si n8n a commencé à se comporter comme ceci (fausses erreurs « sous-workflow non publié » et conditions de concurrence) simplement en doublant le nombre de sous-workflows et d’exécutions, devrais-je m’inquiéter du fait que simplement faire croître mon prod normal avec plus de sous-workflows imbriqués au fil du temps déclenchera les mêmes bugs ? Y a-t-il une limite connue ou un problème connu concernant le nombre de sous-workflows imbriqués ou les exécutions concurrentes sur le plan Pro ?
- Quel est le moyen recommandé de construire un environnement de dev dans ma situation ? Je ne peux pas facilement rediriger les webhooks, j’ai de nombreux sous-workflows imbriqués, et je veux tester les mêmes données réelles que prod reçoit.
Quel est le message d’erreur (le cas échéant) ?
« sous-workflow non publié » sur des sous-workflows qui sont en réalité publiés, plus des erreurs de condition de concurrence intermittentes sur les nœuds utilisant les Tables de données n8n.
Partagez la sortie retournée par le dernier nœud
(l'appel de sous-workflow qui échoue retourne l'erreur « sous-workflow non publié » au lieu de s'exécuter)
Informations sur votre configuration n8n
- Version de n8n : 2.25.7
- Base de données (par défaut : SQLite) : n8n par défaut
- Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) : par défaut (géré par n8n Cloud)
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : n8n Cloud
- Système d’exploitation : n8n Cloud
- Plan : Pro, environ 30 000 exécutions/mois
Bonjour @pohgen
Étant donné que vous avez 15+ workflows imbriqués et que vous rencontrez des conditions de concurrence, vous avez dépassé l’approche « instance unique » pour le développement.
Le standard de référence pour n8n est d’avoir une instance n8n complètement séparée pour Dev. Puisque vous ne pouvez pas modifier la source du webhook, utilisez votre instance Prod comme « proxy muet ».
- Instance Prod : Reçoit le webhook → Envoie immédiatement une HTTP Request à l’URL du webhook de l’instance Dev → Poursuit avec la logique Prod.
- Instance Dev : Un compte/une instance n8n Cloud totalement séparés.
- Pourquoi ça fonctionne : L’instance Dev a sa propre base de données. Il y a zéro contention de ressources. Si l’instance Dev plante ou se bloque, cela n’a aucun impact sur votre exécution Prod.
Salut @koushikromel
J’avais un pipeline de développement exactement comme tu le mentionnes : à chaque déclenchement j’avais un nœud if/else qui vérifiait une variable globale (dev : on/off) puis un nœud HTTP POST qui envoyait (passait) les données au dev. Bien que j’aie compris que cette logique ne devrait pas potentiellement surcharger les ressources, j’ai quand même rencontré un comportement inattendu de la part de n8n. Peut-être que n8n a des limites de ressources quand il est hébergé dans le cloud ?
salut @pohgen
pour répondre à tes questions spécifiques :
- Il n’y a pas de limite matérielle documentée sur les sous-workflows. Le problème que tu as rencontré n’est pas une question de nombre, c’est une question de SQLite et de concurrence. Ton instance Cloud utilise SQLite par défaut, et SQLite a un verrou à écrivain unique. Quand tu as doublé ton pipeline, les copies prod et dev écrivaient dans les mêmes Data Tables simultanément, ce qui a causé une contention d’écriture. Les erreurs « unpublished sub-workflow » sont probablement un effet secondaire de cette contention : quand n8n ne peut pas résoudre une référence de sous-workflow assez vite sous la pression des ressources, il peut générer des erreurs trompeuses. Donc faire croître ton prod normal au fil du temps ne causera pas le même problème à moins que tu doublas aussi les écritures concurrentes vers les Data Tables.
- Pour un environnement de développement sur Cloud, l’approche avec instance séparée de kjooleng fonctionne. Une alternative moins chère qui reste dans une seule instance : au lieu de dupliquer tout le pipeline, utilise le versioning de workflows de n8n. Fais des modifications dans un workflow, enregistre sans publier, puis teste manuellement. Les exécutions en production utilisent toujours la version actuellement publiée, donc ton prod continue d’exécuter la dernière version publiée tandis que tu testes les modifications sur le brouillon enregistré. Une fois validé, publie. Cela ne couvre pas les tests avec le trafic live des webhooks, mais ça évite complètement le problème de duplication.
Pour les tests de trafic live spécifiquement, l’approche proxy-vers-instance-séparée de kjooleng est le bon choix.
J’espère que ça t’aide !
@pohgen bonne nouvelle : pas de limite stricte sur les sous-workflows imbriqués, la croissance de la prod ne déclenchera pas cela. Sur Cloud, la concurrence (Pro = 50) ne compte que les exécutions webhook/trigger, pas les appels Execute Workflow, donc plus de sous-workflows imbriqués ne consomment pas votre budget.
Ce qui l’a cassé, c’est le clonage du pipeline dans la même instance : les erreurs « unpublished sub-workflow » sont des copies prod et dev qui entrent en collision (les sous-workflows dupliqués laissent Execute Workflow accéder à la mauvaise copie/non publiée), les courses Data Table sont les deux copies martelant les mêmes tables intégrées à la fois, et vous avez doublé les exécutions webhook qui comptent vers la limite de 50. La suppression de la copie dev qui fixe tout confirme que c’est la duplication, pas le nombre.
Pour le dev : utilisez une instance n8n séparée avec ses propres Data Tables pour qu’elle ne rentre pas en contention avec la prod. Pour tester des données réelles sans changer de destination les webhooks, capturez les payloads prod et rejouez-les dans dev plutôt que de forker le trafic en direct.