Gatilho do Telegram parou de receber atualizações - nenhuma execução apesar do fluxo de trabalho ativo

Perguntas
1

O problema: Apesar disso, enviar uma nova mensagem para o bot não dispara mais nenhuma execução. A aba Execuções não mostra novas entradas — a última execução bem-sucedida foi há mais de um dia, antes de eu começar a fazer alterações. Tentei:
• Desativar/reativar o fluxo de trabalho várias vezes, aguardando entre as alternâncias
• Criar uma nova credencial do Telegram com o mesmo token do bot e trocar para o nó Trigger (o teste de conexão é bem-sucedido, mas nenhuma nova execução aparece)
• Confirmar que o nó “Enviar mensagem de foto” tem um Chat ID fixo apontando para o canal correto (não um Chat ID dinâmico)
Pergunta: Existe uma forma de verificar a URL/status atual do webhook que o Telegram registrou para este bot dentro do n8n, ou isso requer chamar a API getWebhookInfo do Telegram diretamente? Suspeito que o registro do webhook ficou “preso” apontando para um dos fluxos de trabalho agora desativados, e reativar o fluxo correto não está forçando o Telegram a registrar novamente o webhook. Como posso forçar o n8n a registrar novamente o webhook de forma limpa?

2

Oi @Marcello1

O Telegram permite apenas uma URL de webhook ativa por token de bot. Se você tiver múltiplos workflows usando o mesmo bot, ou se uma ativação anterior não limpou corretamente, o Telegram pode estar enviando atualizações para uma URL antiga ou incorreta.

Para ver exatamente o que o Telegram registrou, crie um workflow temporário com um nó de HTTP Request e configure-o da seguinte forma:

  • Method: GET
  • URL: https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getWebhookInfo
    • (Substitua <YOUR_BOT_TOKEN> pelo seu token de bot real, mantendo a palavra bot antes dele.)
  • Authentication: Nenhuma (o token está na URL).

O que procurar na resposta:

  • url: Este é o campo mais importante. Verifique se esta URL corresponde à sua URL de webhook de produção atual do n8n. Se apontar para um domínio antigo, um IP local ou uma instância n8n diferente, você encontrou o problema.
  • has_custom_certificate: Se você estiver usando certificados autoassinados, isso pode ser relevante.
  • pending_update_count: Se este número for alto, significa que o Telegram está tentando enviar mensagens para uma URL que não está respondendo (provavelmente a antiga).
  • last_error_message: Isto dirá se o Telegram está falhando em alcançar sua instância n8n (por exemplo, “Connection refused” ou “SSL error”).

Atualmente não existe um painel integrado no n8n para visualizar o status do webhook registrado nos servidores do Telegram. Para diagnosticar e corrigir isso, você deve seguir estas etapas usando o nó de HTTP Request do n8n.

Se a URL estiver errada ou “presa”, você pode forçar uma redefinição seguindo esta sequência:

  1. Desative TODOS os workflows no n8n que usam este token de bot específico do Telegram. Isso evita que eles compitam pela registração do webhook.
  2. Limpe o webhook no Telegram: Crie outro nó de HTTP Request para chamar o método deleteWebhook.
    • Method: POST
    • URL: https://api.telegram.org/bot<YOUR_BOT_TOKEN>/deleteWebhook
    • Execute uma vez. Isso diz ao Telegram para parar de enviar webhooks completamente para este bot.
  3. Verifique a redefinição: Execute a solicitação getWebhookInfo da Etapa 1 novamente. O campo url agora deve estar vazio.
  4. Reative seu workflow alvo: Volte para seu workflow desejado e alterne-o para Active.
    • Quando você ativa um Telegram Trigger, o n8n envia automaticamente uma solicitação setWebhook ao Telegram com sua URL de produção atual.

Ajudou?

3

Oi @Marcello1 Bem-vindo!

Uma coisa para adicionar no post do @kjooleng antes de você executar essa sequência. Use deleteWebhook?drop_pending_updates=true em vez de apenas deleteWebhook. O Telegram vem enfileirando cada mensagem enviada para seu bot desde que quebrou, e se esse acúmulo ainda estiver lá quando você re-registrar, será entregue tudo de uma vez. Com um dia de mensagens enfileiradas isso são muitas execuções disparando ao mesmo tempo, e seu nó Send a photo vai felizmente postar todas elas.

Também vale a pena ler last_error_message de getWebhookInfo antes de mudar qualquer coisa. Se disser algo como connection refused, erro de SSL ou resposta incorreta, então o registro nunca foi o problema, o Telegram simplesmente não consegue alcançar sua instância. Deletar e re-registrar não vai consertar isso e você estará aqui de novo amanhã.

O que me faz perguntar, quais foram as mudanças que você fez pouco antes de parar? Uma mudança de domínio, um novo proxy ou uma renovação de certificado produziriam exatamente isso, e o webhook pareceria estar corretamente registrado o tempo todo.

4

Oi @Marcello1
Ao clicar em Execute step ou Execute workflow em um Telegram Trigger enquanto o workflow está publicado, a registração do Telegram é trocada para a URL de teste, e a URL publicada para de receber eventos até que você publique novamente. Isso se encaixa no cronograma, já que quebrou enquanto você estava editando. Despublique o workflow, faça seus testes na URL de teste e depois publique, ou mantenha um segundo token de bot do BotFather puramente para testes, assim os dois nunca se sobrescrevem.
Uma coisa sobre o diagnóstico: execute getWebhookInfo cerca de 30 segundos após publicar em vez de imediatamente. Há relatos de a URL ser registrada corretamente e depois se limpar segundos depois, o que de fora parece exatamente como um registro que nunca aconteceu.