Was tun, wenn der Chatbot im Stream zweimal antwortet

Bestimme zuerst den Typ des Duplikats

Zwei identische Antworten hintereinander sind nicht ein einziger Defekt, sondern mindestens zwei verschiedene. Erster Fall: Der Bot hat ein Ereignis erhalten, aber zweimal. Zweiter Fall: Das Ereignis kam einmal, aber er hat zweimal gesendet. Behandelt werden sie unterschiedlich, also beginne nicht mit der Code-Korrektur – beginne mit den Logs.

Öffne das Bot-Journal und finde den Moment des Duplikats. Schau dir dann zwei Felder an: die Ereignis-ID und den Zeitpunkt des Empfangs.

• Zwei Anfragen mit derselben event_id (oder message_id, notification_id – der Name hängt von der Plattform ab) und einem Unterschied von Millisekunden – das ist die erneute Zustellung eines Ereignisses. Suche nach der Deduplizierung.
• Zwei Anfragen mit unterschiedlichen IDs – auf den Kanal sind tatsächlich zwei Handler abonniert. Suche nach dem zweiten Abonnement.

Wenn es überhaupt keine Logs gibt, beginne mit den Plattform-Panels: Dort ist sichtbar, wer auf die Ereignisse des Kanals abonniert ist.

Wie ein doppeltes Abonnement in den Panels aussieht

Die Plattformen zeigen nicht in einer Zeile „Bot zweimal verbunden“. Die Anzeichen sind über verschiedene Bereiche verteilt.

Twitch

Prüfe den Bereich Connections in den Kontoeinstellungen – dort ist die Liste der verbundenen Anwendungen. Derselbe Bot kann sowohl als Anwendung des Kanals als auch als Anwendung deines persönlichen Kontos autorisiert sein. Zudem leben EventSub-Abonnements separat: Die Anwendung kann ein aktives Abonnement auf channel.chat.message behalten, nachdem du die Integration im Panel deaktiviert hast. Eine zweite lokal gestartete Bot-Instanz erhält ebenfalls Ereignisse gleichberechtigt mit der produktiven.

YouTube

Hier ist häufiger nicht der Bot selbst schuld, sondern der Zugang zum Chat: Der Bot ist mit der Übertragung sowohl als Moderator als auch als separates Teilnehmerkonto verbunden. Schau dir die Moderatorliste und die Liste der autorisierten Anwendungen des Kanals an. Separat: Wenn der Bot über mehrere Google-Cloud-Projekte läuft, können die Schlüssel über zwei verschiedene Wege laufen.

Discord

Der anschaulichste Fall: zwei Anwendungen mit demselben Token auf einem Server. Beide sehen die Nachricht im Kanal und beide antworten darauf. Prüfe die Bot-Liste auf dem Server und stelle sicher, dass kein zweiter Webhook mit demselben Namen mit dem Kanal verbunden ist.

Der Nachteil dieses Weges – man braucht Zugang nicht nur zum Bot, sondern auch zu den Panels des Kanals. Wenn mehrere Personen den Kanal betreiben, könnte jemand anderes die zweite Instanz gestartet haben, und du weißt nichts davon.

Webhook-Wiederholung: Warum das Ereignis zweimal kommt

Ein externer Dienst stellt den Webhook zu und wartet auf eine Bestätigung. Hat er sie nicht innerhalb der vorgegebenen Zeit erhalten, sendet er erneut. Die zweite Anfrage trägt dasselbe Ereignis, aber der Bot nimmt sie als neues wahr und antwortet wieder. Das passiert bei jedem Hängen des Servers: Je größer die Last, desto häufiger.

Behoben wird das durch Deduplizierung auf der Bot-Seite. Man braucht einen Schlüssel, der für alle Kopien eines Ereignisses gleich und für verschiedene Ereignisse eindeutig ist. Der Schlüssel wird aus dem Request-Body oder den Headern entnommen – das hängt von der API ab, aber das Schema ist gleich.

Beispiel eines Deduplizierungsschlüssels

Stell dir einen Webhook über eine neue Spende vor. Im Body kommt ein Objekt mit dem Feld id – einer eindeutigen Transaktionsnummer, die sich bei erneuter Zustellung nicht ändert. Die Logik ist folgende:

1. Ziehe beim Empfang der Anfrage die id aus dem Body.
2. Prüfe im Speicher (Redis, Tabelle in der Datenbank), ob sie in den letzten, sagen wir, 24 Stunden vorgekommen ist.
3. Wenn ja – antworte dem Dienst „angenommen“ und sende nichts in den Chat.
4. Wenn nicht – speichere sie und verarbeite wie gewohnt.

Der Schlüssel muss genau aus dem Ereignis stammen und nicht von dir generiert sein: Wenn du einen eigenen generierst, bekommen zwei Zustellungen eines Ereignisses unterschiedliche Schlüssel, und die Deduplizierung greift nicht. Manche Plattformen liefern einen fertigen Header mit der Zustellungs-ID – dann nimm diesen, das ist zuverlässiger. Der Nachteil des Ansatzes – man braucht einen Speicher und eine Löschrichtlinie, sonst wächst die Schlüsseldatenbank unbegrenzt.

Wenn das Duplikat aus zwei verschiedenen Quellen kommt

Eine separate Geschichte – wenn das Ereignis sich nicht wiederholt, sondern tatsächlich von zwei Stellen kommt. Der Klassiker: Der Bot antwortet auf einen Befehl sowohl im Chat als auch in der Weiterleitung zwischen Plattformen über eine Bridge. Oder die Autoantwort ist auf zwei Trigger eingestellt, die auf dieselbe Phrase reagieren.

Solche Duplikate unterscheiden sich in den Logs von der Webhook-Wiederholung: Die Anfragen haben verschiedene Quellen (verschiedene Plattformen, verschiedene Handler), aber ein semantisches Ereignis. Suche nach der Überschneidung der Trigger und deaktiviere einen davon. Bei einer Bridge – leite die Nachrichten des Bots selbst nicht zurück.

Prüfung vor dem Stream

1. Sende einen Testbefehl und schau, wie viele Antworten kamen.
2. Deaktiviere alle Integrationen außer einer, wiederhole.
3. Aktiviere sie eine nach der anderen, bis das Duplikat zurückkehrt – so findest du den Übeltäter.
4. Vergleiche anhand der Logs die Ereignis-ID bei beiden Antworten: gleich – erneute Zustellung, unterschiedlich – zweites Abonnement.

Wenn die Ursache nicht gefunden wird, deaktiviere die Autoantwort auf das problematische Ereignis und schreibe dem Support des Dienstes mit Logs und der Zeit der Wiederholung. Während du wartest – führe den Chat manuell: besser, die Automatisierung für einen Abend zu verlieren, als den Stream mit identischen Phrasen zu fluten.