Wat te doen als de chatbot live twee keer antwoordt

Bepaal eerst het type duplicaat

Twee identieke antwoorden achter elkaar zijn niet één storing, maar minstens twee verschillende. Eerste geval: de bot heeft één gebeurtenis ontvangen, maar twee keer. Tweede: er kwam één gebeurtenis binnen, maar hij heeft twee keer verzonden. Ze worden verschillend verholpen, dus begin niet met het aanpassen van de code — begin met de logs.

Open het logboek van de bot en zoek het moment van de duplicaat. Kijk vervolgens naar twee velden: de gebeurtenis-id en het tijdstip van ontvangst.

• Twee verzoeken met dezelfde event_id (of message_id, notification_id — de naam hangt af van het platform) en een verschil van milliseconden — dat is herhaalde levering van één gebeurtenis. Zoek naar deduplicatie.
• Twee verzoeken met verschillende id's — er zijn echt twee handlers op het kanaal geabonneerd. Zoek naar het tweede abonnement.

Als er helemaal geen logs zijn, begin dan met de panels van de platforms: daar is te zien wie op de gebeurtenissen van het kanaal is geabonneerd.

Hoe een dubbel abonnement er in de panels uitziet

Platforms tonen niet in één regel "bot twee keer verbonden". De signalen staan verspreid over verschillende secties.

Twitch

Controleer de sectie Connections in de accountinstellingen — daar staat de lijst met verbonden applicaties. Dezelfde bot kan zowel als applicatie van het kanaal als als applicatie van je persoonlijke account geautoriseerd zijn. Bovendien leven EventSub-abonnementen apart: een applicatie kan een actief abonnement op channel.chat.message houden nadat je de integratie in het panel hebt uitgeschakeld. Een tweede exemplaar van de bot dat lokaal draait, ontvangt ook gebeurtenissen naast de werkende.

YouTube

Hier is vaker niet de bot zelf de schuldige, maar de toegang tot de chat: de bot is met de uitzending verbonden zowel als moderator als als afzonderlijk deelnemend account. Bekijk de lijst met moderators en de lijst met geautoriseerde applicaties van het kanaal. Apart: als de bot via meerdere Google Cloud-projecten werkt, kunnen sleutels via twee verschillende paden lopen.

Discord

Het meest duidelijke geval: twee applicaties met hetzelfde token op één server. Beide zien het bericht in het kanaal en beide antwoorden erop. Controleer de lijst met bots op de server en zorg dat er geen tweede webhook met dezelfde naam met het kanaal is verbonden.

Het nadeel van deze route is dat je niet alleen toegang tot de bot nodig hebt, maar ook tot de panels van het kanaal. Als meerdere mensen het kanaal beheren, kan iemand anders een tweede exemplaar hebben gestart, zonder dat je dat weet.

Herhaalde webhook: waarom een gebeurtenis twee keer binnenkomt

Een externe dienst levert de webhook en wacht op bevestiging. Geen bevestiging binnen de gestelde tijd — dan wordt er nog een keer verzonden. Het tweede verzoek bevat dezelfde gebeurtenis, maar de bot ziet het als nieuw en antwoordt opnieuw. Dit gebeurt bij elke hapering van de server: hoe hoger de belasting, hoe vaker.

Het wordt verholpen met deduplicatie aan de kant van de bot. Je hebt een sleutel nodig die gelijk is voor alle kopieën van één gebeurtenis en uniek voor verschillende. De sleutel wordt uit de body van het verzoek of de headers gehaald — dat hangt af van de API, maar het schema is hetzelfde.

Voorbeeld van een deduplicatiesleutel

Stel je een webhook voor over een nieuwe donatie. In de body komt een object met het veld id — een uniek transactienummer dat niet verandert bij herhaalde levering. De logica is als volgt:

1. Haal bij ontvangst van het verzoek id uit de body.
2. Controleer in de opslag (Redis, een tabel in de database) of het de afgelopen, zeg, 24 uur al is voorgekomen.
3. Als het al is voorgekomen — antwoord de dienst "ontvangen" en stuur niets naar de chat.
4. Zo niet — sla het op en verwerk het zoals gewoonlijk.

De sleutel moet juist uit de gebeurtenis komen, niet door jou zijn gegenereerd: als je je eigen sleutel genereert, krijgen twee leveringen van één gebeurtenis verschillende sleutels, en werkt deduplicatie niet. Sommige platforms geven een kant-en-klare header met een leverings-id — gebruik die dan, dat is betrouwbaarder. Het nadeel van de aanpak is dat je opslag en een opruimbeleid nodig hebt, anders groeit de sleuteldatabase eindeloos.

Als de duplicaat uit twee verschillende bronnen komt

Een apart verhaal is wanneer de gebeurtenis niet wordt herhaald, maar echt van twee plekken komt. Klassiek: de bot antwoordt op een commando zowel in de chat als in de doorsturing tussen platforms via een brug. Of de automatische reactie is ingesteld op twee triggers die op dezelfde zin afgaan.

Zulke duplicaten onderscheiden zich in de logs van een herhaalde webhook: de verzoeken hebben verschillende bronnen (verschillende platforms, verschillende handlers), maar één betekenisvolle gebeurtenis. Zoek de overlap van triggers en schakel er één uit. Voor de brug — stuur de berichten van de bot zelf niet terug.

Controle voor de uitzending

1. Stuur een testcommando en kijk hoeveel antwoorden er kwamen.
2. Schakel alle integraties uit behalve één, herhaal.
3. Schakel ze één voor één in tot de duplicaat terugkomt — zo vind je de schuldige.
4. Vergelijk in de logs de gebeurtenis-id van beide antwoorden: dezelfde — herhaalde levering, verschillend — tweede abonnement.

Als de oorzaak niet te vinden is, schakel de automatische reactie op de problematische gebeurtenis uit en schrijf naar de support van de dienst met de logs en het tijdstip van de herhaling. Terwijl je wacht — beheer de chat handmatig: beter een avond automatisering verliezen dan de uitzending vullen met identieke zinnen.