Que faire si le chatbot répond deux fois en direct

Déterminez d'abord le type de doublon

Deux réponses identiques à la suite, ce n'est pas une seule panne, mais au moins deux différentes. Premier cas : le bot a reçu un seul événement, mais deux fois. Second cas : l'événement est arrivé une seule fois, mais il l'a envoyé deux fois. Ils se traitent différemment, donc ne commencez pas par modifier le code — commencez par les logs.

Ouvrez le journal du bot et trouvez le moment du doublon. Ensuite, regardez deux champs : l'identifiant de l'événement et l'heure de réception.

• Deux requêtes avec le même event_id (ou message_id, notification_id — le nom dépend de la plateforme) et un écart de quelques millisecondes — c'est une redélivrance d'un même événement. Cherchez la déduplication.
• Deux requêtes avec des identifiants différents — deux gestionnaires sont réellement abonnés au canal. Cherchez le second abonnement.

S'il n'y a aucun log, commencez par les panneaux des plateformes : on y voit qui est abonné aux événements du canal.

À quoi ressemble un double abonnement dans les panneaux

Les plateformes n'affichent pas « bot connecté deux fois » sur une seule ligne. Les indices sont dispersés dans différentes sections.

Twitch

Vérifiez la section Connections dans les paramètres du compte — elle contient la liste des applications connectées. Un même bot peut être autorisé à la fois comme application de la chaîne et comme application de votre compte personnel. De plus, les abonnements EventSub vivent séparément : une application peut conserver un abonnement actif à channel.chat.message après que vous avez désactivé l'intégration dans le panneau. Une seconde instance du bot, lancée localement, reçoit aussi les événements au même titre que celle qui fonctionne.

YouTube

Ici, le coupable est souvent non pas le bot lui-même, mais l'accès au chat : le bot est connecté à la diffusion à la fois comme modérateur et comme compte participant distinct. Regardez la liste des modérateurs et la liste des applications autorisées de la chaîne. Séparément — si le bot fonctionne via plusieurs projets Google Cloud, les clés peuvent passer par deux chemins différents.

Discord

Le cas le plus parlant : deux applications avec le même token sur un même serveur. Les deux voient le message dans le canal et les deux y répondent. Vérifiez la liste des bots sur le serveur et assurez-vous qu'un second webhook portant le même nom n'est pas connecté au canal.

L'inconvénient de cette voie — il faut avoir accès non seulement au bot, mais aussi aux panneaux de la chaîne. Si plusieurs personnes gèrent la chaîne, une seconde instance a pu être lancée par quelqu'un d'autre, et vous n'en savez rien.

Répétition du webhook : pourquoi l'événement arrive deux fois

Un service externe livre le webhook et attend une confirmation. S'il ne l'a pas reçue dans le délai imparti — il l'envoie encore une fois. La seconde requête porte le même événement, mais le bot la perçoit comme nouvelle et répond de nouveau. Cela se produit à chaque blocage du serveur : plus la charge est élevée, plus c'est fréquent.

Cela se traite par la déduplication côté bot. Il faut une clé identique pour toutes les copies d'un même événement et unique pour des événements différents. La clé est extraite du corps de la requête ou des en-têtes — cela dépend de l'API, mais le schéma est le même.

Exemple de clé de déduplication

Imaginez un webhook sur un nouveau don. Le corps contient un objet avec le champ id — un numéro unique de transaction qui ne change pas lors d'une redélivrance. La logique est la suivante :

1. À la réception de la requête, extrayez l'id du corps.
2. Vérifiez dans le stockage (Redis, une table en base) s'il a déjà été rencontré au cours des dernières, disons, vingt-quatre heures.
3. S'il a été rencontré — répondez au service « reçu » et n'envoyez rien dans le chat.
4. Sinon — enregistrez-le et traitez comme d'habitude.

La clé doit provenir de l'événement lui-même, et non être générée par vous : si vous générez la vôtre, deux livraisons d'un même événement obtiendront des clés différentes, et la déduplication ne fonctionnera pas. Certaines plateformes fournissent un en-tête prêt avec l'identifiant de livraison — prenez-le alors, c'est plus fiable. L'inconvénient de l'approche — il faut un stockage et une politique de nettoyage, sinon la base de clés croît sans limite.

Si le doublon provient de deux sources différentes

Un cas à part — lorsque l'événement ne se répète pas, mais provient réellement de deux endroits. Le classique : le bot répond à une commande à la fois dans le chat et dans un transfert entre plateformes via un pont. Ou bien la réponse automatique est configurée sur deux déclencheurs qui se déclenchent sur la même phrase.

Ces doublons se distinguent de la répétition du webhook par les logs : les requêtes ont des sources différentes (plateformes différentes, gestionnaires différents), mais un seul événement sémantique. Cherchez le chevauchement des déclencheurs et désactivez l'un d'eux. Pour le pont — ne renvoyez pas les messages du bot lui-même en retour.

Vérification avant le direct

1. Envoyez une commande de test et regardez combien de réponses sont arrivées.
2. Désactivez toutes les intégrations sauf une, répétez.
3. Activez-les une par une jusqu'à ce que le doublon revienne — vous trouverez ainsi le coupable.
4. Vérifiez dans les logs l'identifiant de l'événement des deux réponses : identique — redélivrance, différent — second abonnement.

Si la cause reste introuvable, désactivez la réponse automatique pour l'événement problématique et écrivez au support du service avec les logs et l'heure de la répétition. En attendant — gérez le chat manuellement : mieux vaut perdre l'automatisation pour une soirée que noyer le direct sous des phrases identiques.