Bonjour, je crée un workflow avec un webhook LINE comme déclencheur, en utilisant le plan starter. Cependant, lorsque plusieurs images/messages sont envoyés simultanément (en supposant 6 webhooks), 3 ou la moitié sont perdus, sans file d’attente ni délai. Le webhook LINE n’affiche aucun message d’erreur. C’est comme si ces trois ne s’étaient jamais produits.
J’utilise n8n cloud
Décrivez le problème/l’erreur/la question
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Partagez le résultat retourné par le dernier nœud
Informations sur votre configuration n8n
- Version d’n8n :
- Base de données (par défaut : SQLite) :
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
- Exécution d’n8n via (Docker, npm, n8n cloud, application de bureau) :
- **Système d’exploitation :
Bienvenue @Natchanan_Kiatrungwi !
C’est un problème de limite de concurrence sur le plan n8n Cloud Starter. Le plan Starter limite le nombre d’exécutions de flux de travail pouvant s’exécuter en parallèle - lorsque plusieurs événements webhook LINE arrivent simultanément, ceux qui dépassent la limite de concurrence sont silencieusement supprimés (pas d’erreur, pas de file d’attente, aucune trace dans la liste d’exécution).
Chaque appel de webhook LINE déclenche une exécution n8n distincte, donc 6 événements simultanés vont probablement atteindre la limite et certains seront silencieusement ignorés. Il y a deux façons de gérer cela : passer à un plan avec une concurrence plus élevée, ou restructurer votre configuration pour qu’un seul webhook reçoive tous les événements et les traite séquentiellement dans une seule exécution en utilisant le nœud Loop Over Items. Vous pouvez également vérifier la limite de concurrence de votre plan sous Paramètres > Exécutions dans n8n Cloud.
Bonjour @Natchanan_Kiatrungwi
En complément de ce que @nguyenthieutoan a mentionné, vous pouvez également faire ceci :
- Ouvrez votre nœud LINE Webhook.
- Recherchez le paramètre HTTP Response Code.
- Changez le Response Mode de
When Last Node Finishes à Immediately.
Pourquoi cela fonctionne : En répondant « Immediately », n8n envoie un 200 OK à LINE dès la milliseconde où la requête est reçue. Cela ferme la connexion instantanément et libère l’« emplacement » pour le prochain webhook entrant. Le flux de travail continue alors de s’exécuter en arrière-plan. Cela empêche le serveur de s’étouffer sur les connexions ouvertes.
La réponse ci-dessus le précise : c’est le plafond de concurrence sur n8n Cloud Starter. Quand six webhooks LINE arrivent en même temps, les exécutions qui dépassent la limite de parallélisme de votre plan sont supprimées, et le pire, c’est exactement ce que vous avez vu, aucune erreur, aucune file d’attente, aucune trace, les trois ne se sont tout simplement jamais exécutés. C’est le pire type de défaillance car rien ne le signale.
Deux façons de gérer ça. La rapide, c’est de faire en sorte que le webhook fasse le minimum et se termine vite : avoir le workflow déclencheur qui pousse immédiatement le payload entrant dans une file d’attente ou une Data Table (ou un deuxième workflow via une file d’attente), afin que le webhook lui-même revienne en quelques millisecondes et soit beaucoup moins susceptible d’être celui qui sera supprimé lors d’une rafale. L’exécution qui fait le vrai travail draine ensuite la file d’attente à son propre rythme. L’autre, c’est la correction au niveau du plan : les niveaux supérieurs augmentent le plafond de concurrence, donc si les rafales de messages simultanés sont normales pour ce client, le plafond Starter continuera à causer des problèmes.
De toute façon, ajoutez un compteur que vous pouvez voir : enregistrez chaque webhook entrant au moment où il arrive (avant tout traitement) afin que vous puissiez comparer reçus-vs-traités et saurez réellement quand LINE a envoyé plus que ce que n8n a traité. En ce moment, les supprimés sont invisibles, et l’invisible est ce qui rend ça dangereux sur un workflow client. Les rafales sont-elles prévisibles (une campagne) ou aléatoires ? Ça décide file d’attente vs amélioration de plan.
Merci à tous pour vos commentaires très utiles ! Le burst n’est pas séquentiel - juste un ordre aléatoire. Maintenant, j’utilise Hookdeck pour faciliter la mise en file d’attente.
Une autre cause racine trouvée est que certains webhooks n’ont pas été supprimés, mais deux événements ont été combinés dans un seul webhook.
Je réécris maintenant le code pour les détecter.
Hookdeck est le bon endroit pour mettre en buffer le pic. Le reste de la division se trouve à l’intérieur de la charge utile LINE : un webhook peut contenir plus d’un événement, donc comptabilisez et traitez events[], pas seulement les exécutions de webhooks.
Pour la réécriture, enregistrez trois chiffres pour le même pic : webhooks reçus, événements LINE à l’intérieur de ces webhooks, et événements traités. Si ces chiffres correspondent, la queue est correcte et le bug se trouve dans l’analyseur par événement.
Natchanan, tu as écrit que la moitié des webhooks LINE ont été abandonnés sans erreur et que tu as déplacé la file d’attente vers Hookdeck. Avant ce correctif, combien t’ont coûté les messages perdus ?