Olá, estou criando um workflow com LINE webhook como trigger, usando o plano starter. No entanto, quando múltiplas imagens/mensagens são enviadas simultaneamente (assumindo 6 webhooks), 3 ou metade delas são perdidas, sem fila ou espera. O webhook do LINE não mostra mensagens de erro. É como se os três nunca tivessem acontecido.
Estou usando n8n cloud porém
Descrever o problema/erro/pergunta
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
(Selecione os nós no seu canvas e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
Compartilhe o resultado retornado pelo último nó
Informações sobre sua configuração de n8n
- Versão n8n:
- Banco de dados (padrão: SQLite):
- Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
- Executando n8n via (Docker, npm, n8n cloud, desktop app):
- Sistema operacional:
Bem-vindo @Natchanan_Kiatrungwi!
Este é um problema de limite de concorrência no plano n8n Cloud Starter. O plano Starter limita quantas execuções de workflow podem ser executadas em paralelo - quando múltiplos eventos de webhook do LINE chegam simultaneamente, os que excedem o limite de concorrência são silenciosamente descartados (sem erro, sem fila, sem rastreamento na lista de execuções).
Cada webhook do LINE dispara uma execução separada do n8n, então 6 eventos simultâneos provavelmente atingirão o limite e alguns serão silenciosamente descartados. Existem duas formas de lidar com isso: fazer upgrade para um plano com maior concorrência, ou reestruturar para que um único webhook receba todos os eventos e os processe sequencialmente dentro de uma execução usando o nó Loop Over Items. Você também pode verificar o limite de concorrência do seu plano em Settings > Executions no n8n Cloud.
Oi @Natchanan_Kiatrungwi
Além do que @nguyenthieutoan mencionou, você também pode fazer isso:
- Abra seu nó LINE Webhook.
- Procure pela configuração HTTP Response Code.
- Mude o Response Mode de
When Last Node Finishes para Immediately.
Por que isso funciona: Ao responder “Immediately”, o n8n envia um 200 OK para o LINE no milissegundo em que a requisição é recebida. Isso fecha a conexão instantaneamente e libera o “espaço” para o próximo webhook recebido. O fluxo de trabalho então continua a executar em segundo plano. Isso evita que o servidor fique sobrecarregado com conexões abertas.
A resposta acima tem isso: este é o limite de concorrência no n8n Cloud Starter. Quando seis webhooks do LINE chegam de uma vez, as execuções acima do limite paralelo do seu plano são descartadas, e a parte chata é exatamente o que você viu: nenhum erro, nenhuma fila, nenhum rastreamento — as três simplesmente nunca aconteceram. Este é o pior tipo de falha porque nada a sinaliza.
Duas maneiras de lidar com isso. A rápida é fazer o webhook fazer o mínimo possível e passar adiante rápido: fazer o fluxo de disparo imediatamente enviar o payload recebido para uma fila ou uma Data Table (ou um segundo fluxo via fila), para que o webhook em si retorne em milissegundos e seja muito menos provável de ser o descartado sob picos. A execução que faz o trabalho real então drena a fila no seu próprio ritmo. A outra é a correção no nível do plano: planos de nível superior aumentam o limite de concorrência, então se picos de mensagens simultâneas são normais para este cliente, o limite do Starter continuará mordendo.
De qualquer forma, adicione um contador que você possa ver: registre cada webhook de entrada no momento em que chega (antes de qualquer processamento) para poder comparar recebido versus processado e realmente saber quando o LINE enviou mais do que o n8n tratou. Neste momento, os descartados são invisíveis, e invisível é o que torna isso perigoso em um fluxo de cliente. Os picos são previsíveis (uma campanha) ou aleatórios? Isso decide fila versus atualização de plano.
Obrigado a todos pelos inputs muito úteis! O burst não é sequencial - apenas ordem aleatória. Agora estou usando Hookdeck para ajudar na fila.
Outra causa raiz encontrada é que alguns webhooks não foram descartados, mas dois eventos foram combinados em um único webhook.
Agora estou reescrevendo o código para capturar esses.
Hookdeck é o lugar certo para armazenar a explosão de requisições. A divisão restante está dentro do payload do LINE: um webhook pode conter mais de um evento, então conte e processe events[], não apenas execuções de webhook.
Para a reescrita, registre três números para a mesma explosão: webhooks recebidos, eventos LINE dentro desses webhooks e eventos processados. Se forem iguais, a fila está bem e o bug está no parser por evento.
Natchanan, você escreveu que metade dos webhooks do LINE foram descartados sem erro e você moveu a fila para Hookdeck. Antes desse conserto, quanto custou para você as mensagens perdidas?