Kaj storiti, ko klepetalni bot v živo odgovori dvakrat

Najprej določite vrsto podvajanja

Dva enaka odgovora zaporedoma nista ena sama okvara, ampak vsaj dve različni. Prvi primer: bot je prejel en dogodek, a dvakrat. Drugi: dogodek je prišel enkrat, bot pa ga je poslal dvakrat. Zdravita se različno, zato ne začnite s popravljanjem kode — začnite z dnevniki.

Odprite dnevnik bota in poiščite trenutek podvajanja. Nato poglejte dve polji: identifikator dogodka in čas prejema.

• Dve zahtevi z istim event_id (ali message_id, notification_id — ime je odvisno od platforme) in razliko v milisekundah — to je ponovna dostava istega dogodka. Iščite deduplikacijo.
• Dve zahtevi z različnimi identifikatorji — na kanal sta dejansko naročena dva obdelovalca. Iščite drugo naročnino.

Če dnevnikov sploh ni, začnite z nadzornimi ploščami platform: tam je vidno, kdo je naročen na dogodke kanala.

Kako je videti dvojna naročnina v nadzornih ploščah

Platforme ne prikažejo »bot je povezan dvakrat« v eni vrstici. Znaki so razpršeni po različnih razdelkih.

Twitch

Preverite razdelek Connections v nastavitvah računa — tam je seznam povezanih aplikacij. Isti bot je lahko pooblaščen tako kot aplikacija kanala kot tudi kot aplikacija vašega osebnega računa. Poleg tega naročnine EventSub obstajajo ločeno: aplikacija lahko ohrani aktivno naročnino na channel.chat.message, potem ko ste integracijo v plošči izklopili. Tudi drugi primerek bota, zagnan lokalno, prejema dogodke enako kot delujoči.

YouTube

Tu je pogosteje kriv ne sam bot, ampak dostop do klepeta: bot je povezan s prenosom v živo tako kot moderator kot tudi kot ločen račun udeleženca. Poglejte seznam moderatorjev in seznam pooblaščenih aplikacij kanala. Ločeno — če bot deluje prek več projektov Google Cloud, lahko ključi potujejo po dveh različnih poteh.

Discord

Najbolj nazoren primer: dve aplikaciji z istim žetonom na istem strežniku. Obe vidita sporočilo v kanalu in obe nanj odgovorita. Preverite seznam botov na strežniku in se prepričajte, da v kanal ni povezan drugi spletni kavelj z istim imenom.

Slabost te poti je, da potrebujete dostop ne le do bota, ampak tudi do nadzornih plošč kanala. Če kanal vodi več ljudi, je drugi primerek morda zagnal kdo drug, vi pa za to ne veste.

Ponovitev spletnega kavlja: zakaj dogodek pride dvakrat

Zunanja storitev dostavi spletni kavelj in čaka na potrditev. Če je v predvidenem času ne dočaka, ga pošlje še enkrat. Druga zahteva nosi isti dogodek, a bot jo zazna kot novega in znova odgovori. To se zgodi ob vsakem zatikanju strežnika: večja kot je obremenitev, pogosteje.

Zdravljenje je deduplikacija na strani bota. Potrebujete ključ, ki je enak za vse kopije istega dogodka in edinstven za različne. Ključ se vzame iz telesa zahteve ali glav — to je odvisno od API-ja, a shema je enaka.

Primer ključa za deduplikacijo

Predstavljajte si spletni kavelj o novi donaciji. V telesu pride objekt s poljem id — edinstveno številko transakcije, ki se ob ponovni dostavi ne spremeni. Logika je takšna:

1. Ob prejemu zahteve izvlecite id iz telesa.
2. V shrambi (Redis, tabela v bazi) preverite, ali se je pojavil v zadnjih, recimo, štiriindvajsetih urah.
3. Če se je — storitvi odgovorite »sprejeto« in v klepet ne pošljite ničesar.
4. Če se ni — zapišite in obdelajte kot običajno.

Ključ mora izhajati iz dogodka, ne pa da ga ustvarite sami: če ustvarite svojega, bosta imeli dve dostavi istega dogodka različna ključa in deduplikacija ne bo delovala. Nekatere platforme ponujajo že pripravljeno glavo z identifikatorjem dostave — takrat vzemite to, je zanesljiveje. Slabost pristopa je, da potrebujete shrambo in politiko čiščenja, sicer baza ključev raste brez meje.

Če je podvojeni odgovor prišel iz dveh različnih virov

Posebna zgodba je, ko se dogodek ne ponovi, ampak resnično pride z dveh mest. Klasika: bot odgovori na ukaz tako v klepetu kot tudi v posredovanju med platformama prek mostu. Ali pa je samodejni odgovor nastavljen na dva sprožilca, ki se sprožita na isto frazo.

Takšna podvajanja se od ponovitve spletnega kavlja razlikujejo po dnevnikih: zahteve imajo različne vire (različne platforme, različne obdelovalce), a en sam pomenski dogodek. Iščite presečišče sprožilcev in enega izmed njih izklopite. Pri mostu — ne posredujte sporočil samega bota nazaj.

Preverjanje pred prenosom v živo

1. Pošljite testni ukaz in poglejte, koliko odgovorov je prišlo.
2. Izklopite vse integracije razen ene in ponovite.
Vklapljajte jih po eno, dokler se podvajanje ne vrne — tako boste našli krivca.
3. V dnevnikih primerjajte identifikator dogodka pri obeh odgovorih: enak — ponovna dostava, različen — druga naročnina.

Če vzroka ne najdete, izklopite samodejni odgovor na problematični dogodek in pišite podpori storitve z dnevniki in časom ponovitve. Medtem pa vodite klepet ročno: bolje je izgubiti avtomatizacijo za en večer, kot pa prenos v živo preplaviti z enakimi frazami.