Bot ilianza kutoa jibu lilelile mara mbili au tatu kila mtumiaji alipobonyeza kitufe cha kutuma kwa kasi. Marudio hayo yalijitokeza tu kwa watu waliokuwa wakichapa kwa kasi ya kutosha kutuma ujumbe kadhaa kabla ya AI kuanza kufikiri, na yalibaki yakiwa yamejificha kwenye mfumo wa uzalishaji (production) kwa muda mrefu kwa sababu mfululizo huo ulikuwa nadra. Ufungaji wa hifadhidata uliotokea kabla ya wakati (premature database lock) – uliotolewa milisekunde chache baada ya kuchukuliwa – uliacha mazungumzo bila ulinzi, na kuruhusu michakato mingi kujibu swali lilelile.

Kwa nini ufungaji (lock) ulishindwa

Kodi ilipata ufungaji (lock) kupitia wito mmoja wa hifadhidata, kisha ikarudisha udhibiti kwa msimamizi wa ombi (request handler) mara moja. Muda wa kuwepo kwa ufungaji huo ulikuwa wa milisekunde chache, mfupi sana kuliko muda ambao modeli ya AI inahitaji ili kutengeneza jibu. Wakati modeli ilipoanza kazi, ufungaji ulikuwa tayari umeshatoweka, hivyo hakuna kitu kilichozuia ombi la pili kuchukua rekodi ileile ya mazungumzo na kutoa jibu lingine.

Dalili mbili zilitokea:

  • Majibu yanayofanana yalitumwa mfululizo.
  • Majibu yaliyobadilishwa kidogo maneno yalijitokeza kwa swali lilelile, kwani kila mchakato ulijenga ombi (prompt) lake lenyewe kutokana na ingizo lilelile la mtumiaji.

Kwa sababu watumiaji wengi hupumzika kati ya ujumbe, hitilafu hiyo haikuonekana kirahisi. Ni wale wanaochapa kwa kasi sana pekee ndio walioweza kuleta hali ya mashindano (race condition), na matukio hayo yalikuwa nadra.

Suluhisho la nusu-nusu ambalo halikufanikiwa

Hatua ya kwanza ilikuwa kuongeza ucheleweshaji mfupi baada ya ujumbe kuwasili, kwa matumaini ya "kuzuia mfululizo wa haraka" (debounce). Hilo lilisaidia wakati ujumbe wawili ulipowasili kwa mfuatano wa haraka, lakini halikufanya kazi ikiwa ujumbe wa tatu ungeingia wakati AI bado inatengeneza maandishi.

Tatizo la pili lilitokea wakati saa (timers) na data za mazungumzo zilipokuwa katika sehemu moja ya kuhifadhia. Bot ilipomaliza kuchakata ombi, ilifuta na kuandika upya rekodi ya muda (timer), na hivyo kufuta hesabu yake yenyewe ya muda iliyokuwa inasubiri. Mfumo ukapoteza uwezo wa kufuatilia ni ujumbe upi ulishajibiwa, jambo lililofungua mlango wa marudio zaidi.

Kujenga ulinzi wa kuaminika: vihesabu vya toleo, saa zilizotengwa, na leseni

Timu iliboresha mtiririko huo kwa kuzingatia misingi mitatu:

  • Kihisabu cha toleo (Version counter) – kila ujumbe unaoingia huongeza hesabu iliyohifadhiwa kwenye mazungumzo. Kihisabu hicho kinaiambia mifumo ni ujumbe mangapi yameingia tangu jibu la mwisho, jambo linalofanya iwe rahisi kutambua ingizo jipya wakati jibu linatengenezwa.
  • Dirisha maalum la kuzuia mfululizo (Dedicated debounce window) – saa (timers) sasa zinaishi katika eneo tofauti la kuhifadhia, zikiwa zimetengwa na data za mazungumzo. Kikomo cha juu cha muda wa debounce huzuia mtumiaji asizuie bot kwa muda usio na mwisho.
  • Leseni ya kikao (Session lease) – ufungaji (lock) wa awali umebadilishwa na leseni inayobeba muda maalum wa kumalizika (expiry timestamp). Leseni hiyo inachukuliwa kwa kutumia operesheni ya compare-and-swap (CAS): mchakato unasoma thamani ya sasa ya leseni, na kuandika thamani mpya tu ikiwa thamani ya zamani inafanana, na hivyo kupata haki ya kipekee ya mazungumzo hayo. Ikiwa mchakato utafeli, leseni hiyo itamalizika yenyewe, na kuacha mazungumzo kuwa wazi kwa msimamizi mwingine.

Jinsi mfumo mpya unavyofanya kazi

  1. Ujumbe unapowasili – mfumo huongeza kihisabu cha toleo na kuweka upya saa ya debounce. Inarudisha majibu kwa mteja mara moja, bila kuanza AI.
  2. Muda unapokwisha – msimamizi wa saa anajaribu kupata leseni. Ikiwa CAS itafanikiwa, msimamizi huendelea; vinginevyo anajiondoa, akijua kuwa mchakato mwingine tayari unamiliki mazungumzo hayo.
  3. Kukagua kama kuna ingizo jipya – msimamizi analinganisha kihisabu cha toleo cha sasa na thamani aliyorekodi wakati saa ilipoanza. Ikiwa kihisabu kimeongezeka, anaunganisha ujumbe uliokuwa unasubiriwa kuwa ombi (prompt) moja.
  4. Kutengeneza jibu – modeli ya AI inafanya kazi mara moja, ikitoa jibu moja linalojumuisha ingizo zote za hivi karibuni za mtumiaji.
  5. Ukaguzi wa mwisho wa uhakika – kabla tu ya jibu kutumwa, msimamizi anasoma tena kihisabu cha toleo. Ikiwa ujumbe mpya zaidi uliingia wakati wa kutengeneza jibu, jibu hilo linatupwa na mchakato unaanzisha upya saa, kuhakikisha hakuna jibu la zamani linalomfikia mtumiaji.

Njia hii inaondoa majibu ya marudio, inaweka kikomo cha muda ambao mazungumzo yanaweza kusuasua, na inarejea katika hali ya kawaida kiotomatiki kutokana na kufeli kwa michakato kwa sababu leseni huisha yenyewe.

Funzo la kuchukua

Ufungaji (lock) unaotoweka kabla ya sehemu muhimu (critical section) kuanza haitoi ulinzi wowote. Kwa kubadilisha ufungaji wa hifadhidata unaopita haraka na leseni inayomalizika na inayojulikana, pamoja na kutenga saa kutoka kwenye data za mazungumzo, bot sasa inahakikisha jibu moja, la kisasa hata wakati watumiaji wanachapa kwa kasi ya ajabu. Tukio hili linasisitiza funzo la kudumu: kinga za ushindani (concurrency safeguards) lazima zidumu zaidi ya kazi zinazolinda, la sivyo zinakuwa vizuizi visivyoonekana vinavyoruhusu hitilafu kupita.