Les nœuds HTTP Request (GET https://api.attio.com/v2/objects/deals/records/<id>/attributes/stage/values) à l’intérieur d’une boucle Loop Over Items (~510 deals, 2 appels chacun) échouent par intermittence. Un seul appel prend 170–430 ms, mais dans la boucle, certaines requêtes se figent ou expirent. Les pages de statut de n8n, Attio et Cloudflare ne signalent aucun incident.
Quel est le message d’erreur (le cas échéant) ?
connect ETIMEDOUT 172.66.165.206:443
timeout of 8000ms exceeded (ECONNABORTED)
Ce que j’ai essayé :
Retry On Fail (5 tentatives), batching, timeout 15 s → 8 s. Cela aide seulement partiellement. Les nœuds continuent à échouer.
Veuillez partager votre workflow
Configuration autour des nœuds :
Loop Over Items (taille de batch 35) alimente les deux nœuds HTTP Request, qui s’exécutent l’un après l’autre à chaque itération. Après le nœud Merge, un nœud Code et un nœud Wait (amount 3) reviennent à la boucle.
S’agit-il d’un problème connu pour les connexions sortantes de n8n Cloud vers les API fronted par Cloudflare ? Y a-t-il une configuration recommandée (taille de batch, timeout, sous-workflow) pour rendre de telles boucles fiables ? L’équipe n8n pourrait-elle vérifier le chemin réseau de mon instance ?
Informations sur votre configuration n8n
Version n8n : 1.123.89 (Cloud)
Base de données (par défaut : SQLite) : n/a (n8n Cloud, géré)
Le problème provient de l’épuisement du pool de connexions TCP lorsque n8n Cloud effectue des centaines de requêtes HTTP parallèles vers des API protégées par Cloudflare. Les erreurs intermittentes ECONNABORTED et ETIMEDOUT se produisent parce que les tempêtes de poignée de main de connexion submergent l’infrastructure périphérique de Cloudflare (172.66.165.206), ce qui amène le serveur à abandonner les requêtes avant qu’elles ne se terminent.
La solution implique trois optimisations clés : réduire la concurrence en diminuant la taille du lot de boucle de 35 à 5, augmenter les délais d’expiration des requêtes HTTP de 8s à 30s, et mettre en œuvre une limitation de débit pour lisser l’établissement des connexions. L’ajout d’un nœud Rate Limit dédié avec des intervalles de 100ms entre les lots empêche la saturation du pool de connexions, tandis que les paramètres de nouvelle tentative optimisés (3 tentatives au lieu de 5, intervalles de 5s) permettent la récupération de la connexion sans submerger le service en amont.
Pour une fiabilité maximale, envisagez de restructurer le workflow en un sous-workflow contenant uniquement les deux nœuds HTTP Request, avec une gestion d’erreur continue pour les défaillances persistantes. Cette approche offre une meilleure isolation, une gestion des délais d’expiration et des mécanismes de récupération pour la charge de traitement de transactions à haut volume.
Merci pour ta suggestion. Je ne pense pas que la concurrence soit la cause ici, pour trois raisons :
1. J’ai déjà essayé de grouper les requêtes (5 éléments toutes les 250 ms et même 2 éléments par seconde) et des délais d’expiration plus longs (15 s et standard, qui devraient être encore plus longs) avec le même résultat, et mes nœuds de requête HTTP s’exécutent les uns après les autres, il y a donc au maximum 5 requêtes parallèles, pas des centaines. J’ai aussi un nœud d’attente (délai de 3 s) entre chaque boucle. Les tentatives ont déjà été 3 toutes les 2 s et 5 toutes les 3 s. Même résultat.
2. Depuis environ 10 h 30 CET aujourd’hui, la plupart de mes workflows qui appellent api.attio.com échouent de la même manière, y compris les workflows avec seulement quelques requêtes par exécution. Le même schéma s’est produit pendant plusieurs heures il y a deux jours.
3. Plus tôt aujourd’hui, alors que les exécutions dans n8n échouaient, j’ai envoyé 100 requêtes à api.attio.com depuis l’extérieur de n8n Cloud. Les 100 ont reçu une réponse en moins de 0,5 s, sans aucun délai d’expiration. Cela pointe vers le chemin réseau entre n8n Cloud et Cloudflare/Attio plutôt que vers la conception du workflow.
Je pourrais essayer les sous-workflows, qui devraient les rendre plus fiables, mais les mêmes workflows fonctionnaient bien en dehors de la panne d’aujourd’hui et de celle de mardi.
Je soupçonne toujours que la connectivité de mon instance soit défaillante, mais cela devrait être vérifié par quelqu’un de n8n directement - est-il possible que quelqu’un puisse vérifier cela ? ID d’exécution (entre autres) : 138006
connect ETIMEDOUT signifie que la poignée de main TCP n’a jamais été complétée, donc votre requête n’a jamais atteint Attio du tout. C’est pourquoi aucune modification du batching ou des timeouts n’a changé les choses : ce n’est pas une question de conception de workflow, c’est le chemin entre les IPs de sortie d’n8n Cloud et l’edge Cloudflare d’Attio (172.66.x.x est Cloudflare). Votre test curl depuis l’extérieur fonctionnant correctement tandis que Cloud échoue, c’est cohérent avec ça aussi.
Puisque cela affecte plusieurs workflows non liés à la fois et dure quelques heures, je parierais sur un throttling ou un challenge de Cloudflare sur la plage d’IPs de sortie partagée d’n8n Cloud. Ces IPs sont partagées entre de nombreux clients n8n, donc un voisin bruyant peut faire en sorte que toute la plage soit signalée pendant un moment, puis ça disparaît. Ça vaut la peine de demander au support d’Attio de vérifier leurs logs d’edge pour votre période d’échec (10h30 CET aujourd’hui) et de demander au support d’n8n les IPs de sortie que votre instance utilise pour qu’Attio puisse vérifier la même plage.
Comme mesure provisoire, définissez une retry en cas d’échec avec un backoff long (30s ou plus) au lieu de 2-3s, puisque ces fenêtres de throttling sont beaucoup plus longues que quelques secondes. Si ça continue à revenir, faire passer juste ces appels par un proxy HTTP ou un petit worker que vous contrôlez contourne complètement le problème d’IP partagée.
La requête dans votre erreur affiche aussi /records//attributes/..., donc cet élément semble avoir un ID d’enregistrement vide. Vérifiez l’URL évaluée du nœud Requête HTTP et l’entrée de l’élément 2, puis tracez l’expression d’ID à travers la boucle et la fusion pour voir où elle devient vide. Ajoutez une vérification IF avant la requête pour router les IDs manquants vers un journal au lieu d’appeler Attio, et comparez quelques éléments réussis et échoués. Cet ID vide est une problématique distincte d’un délai d’expiration de connexion TCP, donc je vous conseille quand même d’envoyer l’ID d’exécution et les horodatages au support n8n Cloud pour l’investigation de connectivité.
ETIMEDOUT on connect signifie généralement trop de connexions parallèles, et non une API lente. Vous pouvez aussi ignorer la plupart des appels, car le point de terminaison de requête de dossiers d’Attio retourne les valeurs de chaque transaction, l’étape incluse, donc parcourir quelques requêtes vaut mieux qu’environ 1 000 requêtes individuelles. Sinon, utilisez le Batching sur le nœud HTTP avec un petit batch et un intervalle.
Merci pour ton avis. L’ID vide n’est qu’un problème d’affichage. J’avais remplacé l’ID d’enregistrement réel par un espace réservé entre crochets pointus, et le forum l’a probablement supprimé en le prenant pour une balise HTML. Les requêtes réelles contiennent des ID d’enregistrement valides. *edit : j’ai modifié mon message original pour refléter cela.
J’ai quand même envoyé un e-mail à help@n8n.io avec les détails de la panne. On verra comment ils répondront.
Les nœuds HTTP de ce workflow utilisent déjà le traitement par lots (j’ai essayé différents paramètres ici, par exemple 5 éléments, intervalle de 250 ms), donc il n’y a jamais plus de 5 connexions parallèles. Les mêmes délais d’expiration affectent aussi des workflows non liés avec seulement quelques requêtes à la fois.
Le point de terminaison de requête de records couvrirait les valeurs actuelles, mais j’ai besoin de l’historique complet des étapes (active_from / active_until) par opportunité, qui n’est à ma connaissance disponible que via le point de terminaison des valeurs d’attributs avec show_historic=true. Sinon, c’est une bonne suggestion.
Salut @TristanM, un détail sur le point « au maximum 5 » : dans la version 1.123.89, le regroupement des requêtes HTTP retarde le début de chaque groupe, mais n’attend pas que ce groupe se termine. Un lot ultérieur peut démarrer alors que les requêtes antérieures sont toujours en attente.
Pour un test en série, utilisez une copie avec quelques identifiants de deals connus, définissez Loop Over Deals → Batch Size = 1, et maintenez les deux nœuds HTTP en séquence. Conservez show_historic=true.
Si la même erreur connect ETIMEDOUT se produit, ajoutez cet identifiant d’exécution et les horodatages UTC à votre ticket d’assistance existant. Cela permet au support d’avoir une reproduction en série à partir de la même instance Cloud pour la comparer avec les autres workflows affectés.
comme les erreurs se produisent malgré le batching, les retries et les timeouts ajustés, je commencerais par distinguer les problèmes de connexion lors de la poignée de main TCP (ETIMEDOUT) et les timeouts pendant la requête (ECONNABORTED). Il serait particulièrement intéressant de savoir si les erreurs sont liées au nombre de connexions simultanées ou si elles ne se produisent que sur le chemin réseau entre le cloud n8n et Attio.
Je développe moi-même des automatisations basées sur des API avec Python et n8n et je connais les défis de telles intégrations.
As-tu déjà testé les mêmes appels Attio en dehors du cloud n8n avec une charge comparable ?
Merci, cela semble très plausible. Claude m’avait déjà orienté vers les adresses IP de sortie partagées limitées, mais je ne pouvais pas le confirmer sans l’aide du support de n8n ou d’Attio.
Je vais essayer un délai d’attente plus long. Puisque n8n limite l’attente entre les tentatives à 5 secondes, je pourrais router les erreurs du nœud HTTP Request vers un nœud Wait avec un compteur de tentatives à la place. Cela ne couvrira cependant que les pannes courtes, pas celle de plusieurs heures que j’ai observée cette semaine.
Je vais contacter le support d’Attio pour vérifier si l’une des adresses IP de sortie de mon instance est limitée ou bloquée de leur côté. Je vous redonnerai des nouvelles dès que j’aurai des informations.
Essayez de réduire Loop Over Items à une taille de lot de 1, en conservant les deux appels HTTP et l’attente avant de revenir à la boucle. Cela conserve les 510 contrats et les deux appels par contrat, mais place la pause entre les contrats au lieu d’après chaque lot de 35. Traitez ceci comme un test de cadence, et non comme une correction confirmée des délais d’attente de connexion.
Vous avez déjà activé les nouvelles tentatives, alors consultez aussi Paramètres → Attente entre les tentatives (ms) sur les deux nœuds HTTP Request. Si vous limitez la cadence en fonction d’une limite de débit d’API, définissez ce délai pour qu’il corresponde à l’intervalle autorisé plutôt que de réessayer immédiatement.