Le workflow plante constamment en raison du volume - dois-je effectuer une mise à niveau ? Est-ce que ça fonctionnerait ?

Décrivez le problème/l’erreur/la question

J’exécute un workflow sur un compte n8n cloud et le workflow n’arrête pas de planter avant d’être automatiquement désactivé par n8n. Il semble que ce soit dû au volume considérable d’exécutions, car aucun des nœuds n’a d’erreurs et quand je relance les exécutions une par une, elles réussissent.

J’ai affiné les paramètres de relance des nœuds (réduits de 3 tentatives/2000ms d’attente) pour réduire le temps pendant lequel chaque exécution occupe un emplacement de concurrence, et le plan Pro est limité à 20 exécutions concurrentes. J’ai envisagé une mise à niveau car je pensais que cela pouvait être une solution, mais il ne semble pas que passer au tier de 50 000 exécutions augmente réellement la limite de concurrence.

Quelles sont mes options ?

Salut @Kayla_Campos, en attendant une réponse, voici quelques ressources qui pourraient t’aider :

[details=“Ressources suggérées”]

Automatiquement associées à ta question.

Documentation :

Forum :

  • [Execution runs for a long time (confirmed), then later shows

Salut @Kayla_Campos Bienvenue !

Avant de payer pour une mise à niveau, il vaut la peine de vérifier si la concurrence est réellement le problème. Lorsque vous dépassez la limite sur Cloud, les exécutions supplémentaires se mettent simplement en file d’attente et s’exécutent dans l’ordre FIFO, elles ne plantent pas. Donc rester à 20 concurrent ne devrait pas produire ce que tu vois.

Les exécutions plantées plus n8n qui coupe le workflow généralement pointent vers la mémoire à la place. Si l’instance manque de RAM, elle redémarre et tout ce qui est en cours d’exécution est marqué comme planté, ce qui expliquerait également pourquoi les mêmes réussissent quand tu les réessaies un par un.

Quels statuts exactement affichent les exécutions échouées, et à peu près combien de données chaque exécution traite-t-elle ? S’il s’avère que c’est la mémoire, plus de concurrence ne résoudra pas le problème. Une chose qui pourrait aider de toute façon est de déplacer la partie lourde dans un sous-workflow, puisque les exécutions de sous-workflow ne comptent pas vers la limite de concurrence.

Bonjour @Kayla_Campos

Ceci est la méthode standard pour gérer les pics de volume élevé sans augmenter la concurrence. Au lieu que votre flux de travail fasse le « gros du travail » immédiatement après le déclenchement, vous le divisez en deux flux de travail distincts.

  • Flux de travail A (L’ingestionneur) : Ce flux de travail est déclenché par votre webhook/événement. Son seul rôle est de prendre les données entrantes et de les écrire dans un « tampon » (une base de données comme Supabase/PostgreSQL, une Google Sheet, ou même une structure de données interne n8n si vous utilisez une simple file d’attente). Ce flux de travail se termine en millisecondes, ce qui signifie qu’il libère son emplacement de concurrence presque instantanément.
  • Flux de travail B (Le processeur) : Ce flux de travail s’exécute sur un déclencheur d’horaire (par exemple, toutes les 1 minute). Il extrait un lot d’enregistrements du tampon (par exemple, « Obtenir les 10 premières lignes où traité = faux »), les traite, puis les marque comme « traité ».

Pourquoi cela fonctionne : Vous découpler l’arrivée des données du traitement des données. Vous pouvez avoir 10 000 éléments qui frappent le flux de travail A en une seconde, mais le flux de travail B n’utilisera qu’un seul emplacement de concurrence à la fois, les traitant à un rythme régulier et contrôlé.

Salut @Kayla_Campos,

Bienvenue dans la communauté d’abord, et ensuite pourrais-je savoir quelle est la taille du workflow que tu utilises actuellement ? Comme combien de nœuds y a-t-il et s’il est possible de partager le workflow, ça m’aiderait à trouver quel est le problème et où on pourrait améliorer les choses. Pour l’instant, comme l’a mentionné @Hammad_gaming, je pense que le problème vient plutôt de la mémoire. Pourrais-tu partager ce que tu vois dans l’onglet des exécutions ?

Merci

Salut @appunitsai merci !

J’ai téléchargé quelques captures d’écran. Une du workflow et deux des exécutions. Ça fonctionne pendant quelques jours mais ensuite il y a beaucoup d’événements / déclencheurs à la fois et ça provoque des erreurs à répétition comme tu peux le voir et ensuite n8n l’arrête. Je ne vois pas de détails sur les erreurs dans les exécutions elles-mêmes.

@Kayla_Campos

J’ai examiné vos captures d’écran, les durées aident. Vos bons cycles se terminent en 2 à 6 secondes mais chaque cycle échoué dure environ 57 secondes, ce qui ressemble plus à un dépassement de délai juste sous la minute qu’à un problème de volume en soi. Ceux sans aucune durée ont probablement planté plutôt que généré une erreur, c’est pour ça qu’il n’y a aucun détail quand vous les ouvrez.

Si c’est ce qui se passe, plus de concurrence ne le résoudra pas. Ce qui aiderait, c’est de ne pas exécuter une exécution par événement Loops, puisqu’un envoi de campagne déclenche une exécution par destinataire et vous en recevez des centaines à la même seconde. Faire en sorte que le webhook écrive la charge utile quelque part et qu’un flux de travail planifié la traite par lots transforme cela en une poignée d’exécutions.

Quand vous ouvrez l’un de ceux de 57 secondes, affiche-t-il quelque chose, même un nœud rouge ?

Salut @Kayla_Campos Bienvenue !
L’upgrade augmente bien la limite, juste pas le chiffre que tu as vérifié. Les ressources cloud varient selon le plan : Pro-1 (10k) c’est 640MiB de RAM et 10 millicore de CPU en rafale, Pro-2 (50k) c’est 1280MiB et 80 millicore. La concurrence reste à 20 sur les deux, donc ce chiffre ne change pas tandis que la mémoire double et le CPU quadruple.
20 millicore est la véritable contrainte sur un workflow de 25 nœuds. Le processus d’n8n lui-même consomme en moyenne 180MiB, ce qui laisse environ 460MiB et cette fraction de cœur pour tout ce qui s’exécute, donc une campagne Loops qui envoie 15 événements dans la même seconde signifie 15 exécutions qui se battent pour les ressources. Le tier 50k est le seul changement Cloud qui augmente les deux à la fois.

Plus sur les différences entre les tiers :

Merci @Kayla_Campos d’avoir partagé les captures d’écran, c’est maintenant beaucoup mieux !

La raison pour laquelle vous ne recevez pas d’erreurs est que vous avez sélectionné l’option suivante :
Sur Erreur → Continuer

Maintenant, d’après les captures d’écran fournies, je ne crois pas qu’il s’agisse d’un problème de mémoire ni de demandes concurrentes, mais plutôt des demandes adressées à l’API Attio. Or, selon la documentation de l’API Attio ici :

la limite de débit est de 100 demandes par seconde pour les demandes de lecture et de 25 demandes par seconde pour les demandes d’écriture.

Il existe maintenant plusieurs raisons à ce problème, par exemple :

  • Limitation du débit
  • Mauvais paramètre envoyé à Attio

Supposons que les données envoyées soient valides. Voici comment résoudre le problème :
1- Veuillez modifier Sur Erreur → Continuer pour que ce soit : Arrêter le flux de travail ou Continuer (en utilisant la sortie d’erreur). Je recommande d’utiliser Continuer (en utilisant la sortie d’erreur)

2- Si nous utilisons l’option Continuer (en utilisant la sortie d’erreur), nous pourrions recevoir quelque chose comme ceci de la réponse de l’API Attio :

HTTP/1.1 429 Too Many Requests
Retry-After: Tue, 25 May 2023 14:42:01 GMT
Content-Type: application/json

{
"status_code": 429,
"type": "rate_limit_error",
"code": "rate_limit_exceeded",
"message": "Rate limit exceeded, please try again later"
}

Maintenant, nous pouvons analyser l’en-tête Retry-After et ajouter ensuite un nœud d’attente, puis réessayer la demande après le délai spécifié dans l’en-tête Retry-After, quelque chose comme ceci :

Notez que j’ai utilisé un nœud if ici comme exemple pour vérifier l’erreur renvoyée et au cas où ce serait une erreur de limitation de débit, nous allons au nœud d’attente. Bien sûr, nous pouvons utiliser un nœud switch, etc. Je montre juste un exemple.

La plupart des défaillances prennent environ 57 secondes, c’est donc un problème de délai d’expiration et je suis presque certain à 100 % qu’il s’agit des appels d’API à Attio. Pourriez-vous donc effectuer les modifications ci-dessus et nous partager les résultats ?

Merci

Rien de ce qui a été montré jusqu’à présent ne prouve ni une limite de mémoire n8n ni une limite de débit Attio. Un temps d’exécution répété proche de 57 secondes est une signature de synchronisation, pas une cause. On Error: Continue peut également masquer la réponse du nœud qui distinguerait ces cas.

Pour une exécution contrôlée, basculez les nœuds Attio sur Continue (using error output) et capturez le statut réel, le corps de la réponse et les en-têtes. En cas de blocage sans durée, fournissez au support Cloud l’ID d’exécution et l’horodatage et demandez si l’instance a redémarré. Ce sont des défaillances différentes et ne doivent pas être ajustées ensemble.

Ne faites pas de mise à niveau pour la concurrence. Les deux niveaux abordés ici maintiennent la limite à 20. Procédez à une mise à niveau uniquement si le support confirme l’épuisement des ressources, ou si l’exécution contrôlée montre que le niveau de calcul actuel est le goulot d’étranglement. Si la sortie d’erreur affiche 429, respectez Retry-After et lissez la rafale entrante avant qu’elle n’atteigne Attio.

Merci, j’ai basculé les nœuds Attio sur Continue en utilisant la sortie d’erreur, le flux de travail était toujours désactivé après quelques jours en raison de plantages et il n’affiche toujours aucune erreur, il affiche qu’il a réussi.

Cette dernière partie est l’important : elle affiche succès et pourtant ça s’est arrêté. Quand une exécution signale un succès et que quelque chose ne va toujours pas, le champ status n’est pas là où se trouve la réponse.

J’ai rencontré ce problème dans mon propre moteur, pas dans n8n, mais la structure est la même. J’ai trouvé 27 branches cassées dans mes définitions de workflow. Certaines ont été silencieusement ignorées, d’autres ont silencieusement s’exécutées, et chaque exécution s’est toujours terminée en COMPLETED de toute façon. On Error → Continue fait la même chose ici : il transforme une défaillance visible en une défaillance invisible.

Ce qui fonctionne pour moi, c’est de vérifier la sortie au lieu du statut. Ajoutez un nœud après Attio qui affirme que la réponse contient réellement ce que vous attendez, et laissez le workflow échouer intentionnellement si ce n’est pas le cas. Vous verrez ainsi la véritable erreur au lieu d’une exécution en vert.

Ce résultat est plus utile qu’il n’y paraît, en raison de ce qu’il exclut.

Continue (utilisant la sortie d’erreur) ne capture que les erreurs qu’un nœud renvoie. Si l’instance elle-même est supprimée, le processus disparaît en cours d’exécution et aucun chemin d’erreur ne s’exécute du tout, donc rien n’atteint cette branche. Une image inchangée après avoir apporté cette modification est donc une preuve contre une erreur Attio étant ce qui désactive le workflow, et une preuve de l’échec se produisant sous le workflow plutôt qu’à l’intérieur.

La liste des exécutions contient deux populations différentes et une seule d’entre elles est ce qui vous désactive. Les exécutions qui ont une durée et un statut sont des exécutions réelles qui se sont terminées, et celles-ci peuvent être vertes et être quand même incorrectes, ce qui est le cas qu’Aghassi décrit et qui vaut la peine d’être corrigé séparément. Les exécutions sans durée du tout sont celles où le processus a disparu avant de pouvoir écrire quoi que ce soit, c’est pourquoi elles ne contiennent aucun détail quelle que soit la gestion d’erreur que vous définissez. Comptez seulement ce deuxième type dans la fenêtre autour de chaque moment où n8n a désactivé le workflow.

Le test qui le confirme est une copie minimale. Dupliquez le workflow, conservez le même déclencheur, et remplacez l’appel Attio et tout ce qui charge des données par un nœud No Operation. Envoyez-lui la même rafale de Loops. Si la copie meurt aussi, la cause n’est pas Attio et pas votre logique, c’est ce que l’instance peut supporter pendant que ce nombre d’exécutions se chevauchent, et aucune gestion d’erreur ne le changera. Si la copie survit sans problème, alors l’ensemble de travail que chaque exécution porte est ce qu’il faut réduire, et interroger seulement les enregistrements qu’une exécution touche réellement fait plus que n’importe quel paramètre de nouvelle tentative.

Une chose que vous ne pouvez pas voir de l’intérieur du compte : donnez au Cloud Support les ID d’exécution des exécutions sans durée avec leurs horodatages et demandez directement si l’instance a redémarré à ces moments. Cette seule réponse décide si vous ajustez un workflow ou dimensionnez un plan, et c’est une information utile à avoir avant de dépenser quoi que ce soit pour une mise à niveau.

Je suis tombé sur votre message concernant le workflow qui s’arrête répétitivement bien que les nœuds individuels ne montrent aucune erreur.

J’étudie comment les utilisateurs de n8n dépannent ce genre de défaillances. Quand les exécutions semblent réussies mais que le workflow est quand même désactivé, quelle a été la partie la plus difficile pour vous. Déterminer s’il s’agit réellement d’un problème de concurrence/volume, trouver ce qui déclenche les arrêts, ou savoir ce qu’il faut vérifier ensuite ?