Pagpapanatiling Buhay ng Chat Kapag Natutulog ang Phone

Puwedeng magtrabaho nang ilang minuto ang agent ng Mythex sa isang request, at malamang nanonood ka mula sa phone, na nagla-lock, lumilipat ng app, at nagbabago ng network habang gumagana ito. Dalawang bug ang nagpalala nito. Sa isa, itinuring ng chat na patunay na patay na ang koneksyon nito ang bawat signal na “nakikita na ulit ang page”, kaya paulit-ulit itong nag-loop hanggang manatili sa “Connecting…”. Sa isa pa, ang phone na natulog habang dumarating ang unang sagot ng bagong chat ay bumalik na may ilang unang piraso lang ng sagot, hanggang sa mag-refresh nang manu-mano. Parehong naayos na.

Paano sinusundan ng chat ang tumatakbong turn

Habang gumagana ang agent, nagbubukas ang chat ng stream mula sa aming servers: bawat hakbang (isang pag-iisip, isang tool call, isang piraso ng sagot) ay dumarating bilang event. Kapag nawala ang stream, kumokonekta ulit ang chat at ipinapakita ulit ng server ang mga kamakailang event mula sa buffer na nagtatago ng huling 120 segundo. Kapag natapos ang turn, humihingi rin ang chat sa server ng naka-save na kasaysayan at pinagtutugma ang ipinakita nito sa naka-save. Sinasalo ng huling hakbang na iyon ang anumang nalampasan ng stream.

Para malaman kung buhay o patay ang koneksyon kapag walang nangyayari, nagpapadala ang server ng maliit na “ping” bawat 15 segundo.

Bug 1: ang paggising ay pumapatay sa malusog na stream

Sinasabi ng mga browser sa page kapag nakikita na ulit ito: pagkatapos magpalit ng tab, pagkatapos mag-unlock ng screen. Ginamit namin iyon bilang hudyat na suriin ang koneksyon, at sa totoo lang, para i-abort ang stream at kumonekta ulit, sa pag-aakalang namatay ito habang nakatago.

Sa mga phone at embedded browser, mas madalas mangyari ang mga event na ito kaysa sa pagkamatay ng stream: sa bawat pagpalit ng tab, bawat unlock, at sa ilang embedded browser, halos bawat ilang segundo. Bawat isa ay nag-a-abort ng stream na malusog naman. Kumokonekta ulit ang chat, nire-replay, ina-abort ulit, at nauuwi sa “Connecting…”. Pagkatapos, sasabihin nitong natapos na ang turn kahit gumagana pa ang agent.

Ang ayos: husgahan ang stream ayon sa kung nakikipag-usap pa ito

Nire-record na ngayon ng chat kung kailan huling tumanggap ng anuman ang stream ng bawat project, mga event at ang 15-segundong ping man. Ang signal na “nakikita na ulit” ay nag-a-abort lang ng stream na tahimik nang 25 segundo: mas mahaba ito sa ping interval plus ng mabagal na network hop, kaya hindi kailanman kuwalipikado ang buhay na stream. May mga test na nagsusuri na ang isang ping ay bilang ng buhay, at na ang stream na kakapinging lang ay hindi itinuturing na patay.

Ang aral na kinuha namin: ang visibility ng page ay nagsasabi tungkol sa page, hindi tungkol sa koneksyon sa network. Itanong sa koneksyon mismo.

Bug 2: kalahating sagot pagkatapos magising ang phone

Naulit namin ito sa bawat pagkakataon sa iOS simulator:

Magsimula ng bagong chat at magpadala ng request na matagal.
Hayaang matulog ang phone habang nagbu-build.
Bumalik pagkatapos matapos ang turn at mag-expire na ang dalawang minutong replay buffer.

Ipinakita ng chat ang unang ilang bloke ng sagot, minarkahang tapos na, at nanatili ito ganoon hanggang mag-refresh ka ng page.

Bakit

Wala pang thread ang bagong chat, ibig sabihin, ang naka-save nitong usapan, hanggang sa unang mensaheng lumikha nito. Nangyayari iyon sa loob ng send function, pagkatapos na nakuha na ng send ang reconcile step, na inakalang wala pang thread. Kaya sa dulo ng unang turn sa bagong chat, nakita ng reconcile na walang thread at tahimik itong bumalik nang hindi humihingi ng kahit ano.

Karaniwang walang nakapansin, dahil naihatid na ng stream ang buong turn. Pero ang phone na natulog sa kalagitnaan ng turn at bumalik pagkatapos ng 120-segundong replay buffer ay hindi na makakakuha ng nawawalang event mula sa stream, at hindi kailanman tumakbo ang reconcile na dapat sana ay pumuno sa puwang.

Ang ayos

Sinasabi na ng send sa reconcile kung aling thread ang kabilang sa turn, kaya ang unang turn ng bagong chat ay pinagtutugma gaya ng alinman. Kung nakapagbukas ka na ng ibang chat pagdating ng sagot, itatapon ang resulta sa halip na ipakita sa maling lugar.
Inuulit ang reconcile na pumalya. Maaaring makita ng phone na nagising sa masamang koneksyon na tapos na ang turn, pero pumalya itong kunin. Naaalala na ito ngayon, at magtatanong ulit ang chat kapag ipinakita ulit ang tab o bumalik ang network.
Tapat ang “Worked for”. Ipinapakita ng bawat sagot kung gaano katagal nagtrabaho ang agent. Kung hindi nakita ng tab ang end-of-turn message ng server, pinupunan nito iyon mula sa sarili nitong orasan, na tumatakbo mula sa Send hanggang magising ang phone, kasama ang oras ng pagkawala. Minarkahan na ngayon ang figure na iyon bilang tantya, at papalitan ng nakaimbak na tagal kapag dumating na ang kasaysayan.

Ang natutunan namin

Mag-test sa device na talagang ginagamit ng mga tao, sa paraan ng paggamit nila. Parehong bug ay nasa puwang sa pagitan ng “stream na gumagana” at “phone sa bulsa”.
Ang fallback na hindi kailanman tumatakbo ay hindi fallback. Umiiral ang reconcile step para mahuli mismo ang kasong ito, at tahimik nitong nilaktawan.
Ulitin din ang recovery. Ang sandali ng paggising ng phone ay kadalasang kung kailan pinakamasama ang koneksyon nito.
Huwag ipakita ang hula bilang katotohanan. Mas masama ang tagal mula sa maling orasan kaysa walang tagal; lagyan ito ng label o palitan.

Bininis din ng parehong trabaho ang ilang bagay na makikita mo habang tumatakbo ang isang turn: may label na ang mga shell step ayon sa command na gumagawa ng trabaho sa halip na cd, pinananatili ng mga screenshot sa chat ang itaas-kaliwang bahagi ng page at kasya sa column, at nakukuha na ng bagong project ang awtomatikong nabuong pangalan nito nang walang refresh.

Kung gumagawa ka ng sarili mong app para sa phone, sakop ng aming mga guide tungkol sa paggawa ng web app na mabuti sa mobile at native kumpara sa progressive web apps ang mga batayan. Mas marami pang detalye tungkol sa chat mismo sa chat docs.