Le déclencheur Telegram exécute chaque message 3 fois (exécutions en doublon)

Questions
1

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 nodes sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)

Partagez la sortie retournée par le dernier node

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
2

@Wey89_Gmail cela signifie presque toujours que le même jeton de bot est actif dans plus d’un déclencheur Telegram, donc chaque copie traite la même mise à jour. 3x = son activité est en 3 endroits. vérifiez qu’il n’y a pas de workflow dupliqué/copié, une version de test et une version de production toutes deux actives, ou une autre instance n8n utilisant le même bot, et désactivez les copies supplémentaires. Telegram n’autorise qu’un seul déclencheur actif par bot, une fois qu’il n’en reste qu’un seul, les doublons s’arrêtent.

3

Le déclencheur Telegram se déclenche 3 fois par message, c’est presque toujours l’une de ces deux causes :

  1. Plus d’un consommateur est attaché au même jeton de bot. Telegram n’autorise qu’UN seul récepteur actif par bot — soit le polling (getUpdates), soit un seul webhook, jamais les deux, et jamais sur plusieurs instances. Si le même jeton de bot est utilisé dans un autre workflow, une autre instance n8n, ou s’il y a un webhook obsolète d’une activation précédente, Telegram livre la même mise à jour à chacun → doublons.
    Vérifiez : appelez la méthode getWebhookInfo de Telegram pour votre jeton de bot — elle indique si un webhook est actuellement défini plus le nombre de mises à jour en attente. Si vous utilisez le déclencheur Telegram n8n (qui utilise le polling), assurez-vous qu’aucun webhook n’est défini (utilisez deleteWebhook pour nettoyer un webhook obsolète), et confirmez que le jeton n’est pas actif dans un second workflow/instance.

  2. Telegram réessaie parce qu’il n’a pas reçu un 200 rapide. Si le déclencheur n’accuse pas réception dans le délai imparti par Telegram, Telegram renvoie la même mise à jour — vous la verrez souvent arriver 2 à 3 fois. Cela se produit lorsque des opérations lourdes s’exécutent avant l’envoi de la réponse. Solution : accuser réception immédiatement et déléguer les étapes lentes (répondre en premier, puis faire le travail LLM/API, ou le mettre en file d’attente). Trois renvois, c’est une signature de retry classique de Telegram.

Comment les distinguer : si getWebhookInfo affiche un webhook défini alors que vous utilisez aussi le polling, c’est le #1. Si les doublons sont espacés de quelques secondes et que votre workflow est lent, c’est le #2.

Correction qui arrête les doublons quelle que soit la cause : ajoutez un garde anti-déduplication juste après le déclencheur — enregistrez chaque update_id (ou message_id) de Telegram et ignorez si vous l’avez déjà traité. Cela rend le workflow idempotent même si Telegram livre en double.

Quel est votre configuration — auto-hébergée avec plus d’une instance, et utilisez-vous le polling ou le webhook ? Cela le précisera.