Mit tegyünk, ha a chatbot kétszer válaszol az adásban

Először határozzuk meg a duplikáció típusát

Két egyforma válasz egymás után nem egyetlen hiba, hanem legalább kettő, egymástól különböző. Első eset: a bot egy eseményt kapott, de kétszer. Második: az esemény egy volt, de ő kétszer küldte el. A kettőt másképp kell kezelni, ezért ne a kód javításával kezdjük – kezdjük a naplókkal.

Nyissuk meg a bot naplóját, és keressük meg a duplikáció pillanatát. Utána nézzünk két mezőt: az esemény azonosítóját és a beérkezés idejét.

• Két kérés ugyanazzal az event_id-val (vagy message_id, notification_id – a név a platformtól függ), milliszekundumos eltéréssel – ez egy esemény ismételt kézbesítése. Itt a deduplikációt kell keresni.
• Két kérés különböző azonosítókkal – a csatornára valóban két feldolgozó van feliratkozva. Itt a második feliratkozást kell keresni.

Ha egyáltalán nincsenek naplók, kezdjük a platformok paneleivel: ott látszik, ki van feliratkozva a csatorna eseményeire.

Hogyan néz ki a dupla feliratkozás a paneleken

A platformok nem jelenítik meg egyetlen sorban, hogy „a bot kétszer van csatlakoztatva”. A jelek különböző szakaszokban szóródnak szét.

Twitch

Nézzük meg a fiókbeállítások Connections szakaszát – ott van a csatlakoztatott alkalmazások listája. Ugyanaz a bot engedélyezhető csatornaalkalmazásként és a személyes fiókunk alkalmazásaként is. Ráadásul az EventSub-feliratkozások külön léteznek: előfordulhat, hogy az alkalmazás aktív feliratkozást tart fenn a channel.chat.message eseményre, miután a panelfelületen kikapcsoltuk az integrációt. A helyben futtatott második botpéldány is ugyanúgy kapja az eseményeket, mint a működő.

YouTube

Itt gyakrabban hibás nem maga a bot, hanem a csevegéshez való hozzáférés: a bot az élő adáshoz moderátorként és külön résztvevő fiókként is csatlakozik. Nézzük meg a moderátorok listáját és a csatorna engedélyezett alkalmazásainak listáját. Külön eset – ha a bot több Google Cloud-projekten keresztül működik, a kulcsok két különböző útvonalon is haladhatnak.

Discord

A legszemléletesebb eset: két alkalmazás ugyanazzal a tokennel egy szerveren. Mindkettő látja a csatorna üzenetét, és mindkettő válaszol rá. Nézzük meg a szerver botjainak listáját, és győződjünk meg róla, hogy a csatornához nincs csatlakoztatva egy második, ugyanilyen nevű webhook.

Ennek a megközelítésnek a hátránya, hogy nemcsak a bothoz, hanem a csatorna paneleihez is hozzáférés kell. Ha a csatornát többen viszik, a második példányt valaki más indíthatta el, és erről nem tudunk.

Webhook-ismétlés: miért érkezik kétszer az esemény

A külső szolgáltatás kézbesíti a webhookot, és visszaigazolásra vár. Ha a megadott időn belül nem kapja meg, újra elküldi. A második kérés ugyanazt az eseményt hordozza, de a bot újként érzékeli, és ismét válaszol. Ez bármilyen szerverakadásnál előfordul: minél nagyobb a terhelés, annál gyakrabban.

A megoldás a bot oldalán végzett deduplikáció. Olyan kulcs kell, amely egy esemény minden példányánál ugyanaz, a különböző eseményeknél pedig egyedi. A kulcsot a kérés törzséből vagy a fejlécekből vesszük – ez az API-tól függ, de a séma ugyanaz.

Példa a deduplikációs kulcsra

Képzeljünk el egy webhookot egy új adományról. A törzsben egy objektum érkezik egy id mezővel – ez a tranzakció egyedi száma, amely ismételt kézbesítésnél nem változik. A logika a következő:

1. A kérés fogadásakor emeljük ki az id-t a törzsből.
2. Ellenőrizzük a tárolóban (Redis, adatbázistábla), hogy előfordult-e az elmúlt, mondjuk, egy napban.
3. Ha előfordult – válaszoljunk a szolgáltatásnak, hogy „megkaptuk”, és ne küldjünk semmit a csevegésbe.
4. Ha nem – jegyezzük fel, és dolgozzuk fel a szokásos módon.

A kulcsnak magából az eseményből kell származnia, nem általunk generáltnak: ha sajátot generálunk, egy esemény két kézbesítése két különböző kulcsot kap, és a deduplikáció nem működik. Egyes platformok kész fejlécet adnak a kézbesítés azonosítójával – ilyenkor azt vegyük, ez megbízhatóbb. A megközelítés hátránya, hogy tároló és tisztítási szabályzat kell hozzá, különben a kulcsok adatbázisa korlátlanul nő.

Ha a duplikáció két különböző forrásból érkezett

Külön történet, amikor az esemény nem ismétlődik, hanem valóban két helyről érkezik. A klasszikus eset: a bot a parancsra a csevegésben és a platformok közötti hídon keresztüli továbbításban is válaszol. Vagy az automatikus válasz két olyan triggerre van beállítva, amelyek ugyanarra a mondatra aktiválódnak.

Az ilyen duplikációk a naplók alapján különböznek a webhook-ismétléstől: a kéréseknek különböző a forrásuk (különböző platformok, különböző feldolgozók), de egy szemantikai esemény. Keressük a triggerek átfedését, és kapcsoljuk ki az egyiket. A híd esetében – ne továbbítsuk vissza magának a botnak az üzeneteit.

Ellenőrzés az adás előtt

1. Küldjünk egy tesztparancsot, és nézzük meg, hány válasz érkezett.
2. Kapcsoljunk ki minden integrációt egy kivételével, és ismételjük meg.
3. Kapcsoljuk be őket egyenként, amíg a duplikáció vissza nem tér – így megtaláljuk a bűnöst.
4. A naplók alapján vessük össze a két válasz eseményazonosítóját: ha ugyanaz – ismételt kézbesítés, ha különböző – második feliratkozás.

Ha nem találjuk az okot, kapcsoljuk ki az automatikus választ a problémás eseményre, és írjunk a szolgáltatás ügyfélszolgálatának a naplókkal és az ismétlődés idejével. Amíg várunk – vezessük kézzel a csevegést: jobb egy estére elveszíteni az automatizálást, mint teleönteni az adást egyforma mondatokkal.