Je suis sur n8n Cloud Starter, version 2.17.5.
Un workflow qui traite environ 120–400 éléments via Loop Over Items et HTTP Requests reçoit l’erreur « connexion perdue / hors ligne » et l’exécution est interrompue.
Les données d’exécution sont peu fiables ou ne sont pas sauvegardées correctement.
Cela se produit même après avoir réduit la charge utile et utilisé Data Tables.
Pouvez-vous confirmer s’il s’agit d’un problème de ressources/timeout du Cloud et si mon plan peut supporter cette charge de travail ?
Salut @kourG, bienvenue !
Je dirais que ce nombre peut être une limitation de votre plan cloud starter si votre flux de travail n’est pas optimisé, bien que 120-400 soit toujours beaucoup pour l’accès au calcul du plan starter :
Voici quelques conseils que vous pouvez considérer pour optimiser ce flux :
Mettez à niveau votre plan peut aussi résoudre le problème, mais cela dépend de votre cas d’usage ; s’il se développe, vous devrez peut-être aller encore plus haut.
Sur Cloud Starter, 120 à 400 articles en boucle avec Loop Over Items plus HTTP Requests qui rencontrent une « connection lost » dépasse généralement les limites de mémoire ou de temps du plan plutôt qu’une question de connexion internet, particulièrement si chaque article contient un payload volumineux, car n8n conserve les données d’exécution en mémoire pendant la durée de la boucle.
Quelques solutions aident. Réduisez ce que chaque article porte avant la boucle, supprimez les champs dont vous n’avez pas besoin pour que le payload en mémoire reste petit, car la boucle conserve tout. Traitez par plus petits sous-lots et écrivez les résultats au fur et à mesure (dans une Data Table ou un stockage externe) au lieu d’accumuler tout dans une seule exécution, pour qu’une défaillance en cours de route ne perde pas toute la boucle. Et envisagez de diviser le travail : un workflow qui met en file les articles, un deuxième déclenché par lot, pour qu’aucune exécution ne doive conserver l’état de 400 articles.
La partie « données d’exécution non fiables ou non sauvegardées » est le véritable risque pour vous, car une boucle qui meurt en cours de chemin a souvent déjà effectué la moitié des écritures HTTP, et vous ne pouvez pas distinguer lesquelles de l’exécution cassée. Rendez les écritures idempotentes et suivez quels articles ont été traités dans une table externe, pour qu’une réexécution ignore ceux déjà effectués au lieu de les dupliquer. Échoue-t-il à un nombre d’articles constant, ou aléatoirement ? Un nombre constant indique le plafond de mémoire.
Bienvenue dans la communauté n8n @kourG
Pouvez-vous s’il vous plaît mettre à jour vers la version stable 2.23.4 et revenir nous dire si le comportement persiste ?
J’ai déjà essayé de réduire la taille de la charge utile et de stocker les données intermédiaires dans des Data Tables. Cependant, lorsque le problème de « connexion perdue / hors ligne » se produit, aucune donnée ne semble rester dans la table, comme si l’exécution n’avait jamais abouti ou que les résultats intermédiaires n’avaient jamais été enregistrés.
Pour cette raison, j’essaie de comprendre si le problème est lié à une limite de ressources Cloud Starter ou à un délai d’exécution.
Concernant la suggestion d’utiliser des lots, si je comprends bien, vous me recommandez de diviser les 120–400 éléments en groupes plus petits et de les traiter progressivement au lieu de les traiter en une seule grande exécution. Je considère également s’il serait possible de charger un nouveau lot après la fin du traitement du lot actuel dans la boucle, afin que le workflow puisse continuer par petits groupes. Je vais expérimenter cette approche et voir si cela améliore la stabilité.
De plus, j’utilise n8n Cloud Starter et je n’ai pas de contrôle direct sur la mise à niveau de la version d’n8n, puisque la version est gérée par n8n Cloud. Pourriez-vous confirmer si la version 2.23.4 est déjà disponible sur Cloud, ou si une action est requise de la part de l’équipe n8n ?
Oui, mais faites de chaque lot sa propre exécution. Une Loop Over Items qui charge le lot suivant dans la même exécution partage toujours une même enveloppe de timeout/mémoire, donc quand cette exécution est interrompue, le point de contrôle peut disparaître avec elle.
Utilisez une exécution pour réclamer un petit lot, écrivez le résultat/statut de chaque élément avant de passer à l’élément suivant, puis laissez une Schedule ou Execute Workflow démarrer le lot suivant à partir des lignes toujours marquées comme en attente. Pour le symptôme Data Table, postez où se situe le nœud d’écriture : avant la HTTP Request, après chaque élément, ou seulement après la fin de la boucle entière ?