જ્યારે ફોન સૂઈ જાય ત્યારે ચેટ ચાલુ રાખવી

Mythex નો agent એક વિનંતી પર મિનિટો સુધી કામ કરી શકે છે, અને તમે કદાચ ફોન પરથી જોતા હશો — જે લૉક થાય છે, એપ્સ બદલે છે અને કામ કરતી વખતે networks બદલે છે. બે bugs ને લીધે તે ખોટું થતું હતું. એકમાં, ચેટ દરેક "પેજ ફરી દેખાય છે" સંકેતને જોડાણ મરી ગયું હોવાનો પુરાવો ગણતી, અને "Connecting…" પર અટકી જતી. બીજામાં, એક ફોન જે નવી ચેટના પહેલા જવાબ દરમિયાન સૂઈ ગયો હતો, તે પાછો આવતાં ફક્ત તેના પ્રથમ થોડા ટુકડા જોતો, જ્યાં સુધી મેન્યુઅલ refresh ન કરાય. બંને ઠીક થયા છે.

ચેટ ચાલતા turn ને કેવી રીતે અનુસરે છે

agent કામ કરે ત્યારે, ચેટ અમારા સર્વર્સમાંથી એક stream ખુલ્લો રાખે છે: દરેક પગલું — એક વિચાર, એક tool call, જવાબનો એક ટુકડો — એક event તરીકે આવે છે. જો stream તૂટે, તો ચેટ ફરી જોડાય છે, અને સર્વર તાજેતરના events ને એક buffer માંથી ફરી મોકલે છે જે છેલ્લી 120 સેકન્ડ રાખે છે. જ્યારે turn પૂરો થાય, ત્યારે ચેટ સર્વરને સાચવેલો ઇતિહાસ પણ માંગે છે, અને જે બતાવ્યું હતું તેને જે સંગ્રહાયું છે તેની સાથે મેળવે છે. છેલ્લું પગલું stream ચૂકી ગયેલી કોઈપણ વસ્તુ પકડે છે.

જ્યારે કંઈ ન થઈ રહ્યું હોય ત્યારે જીવંત જોડાણ અને મૃત જોડાણ વચ્ચે ફરક કરવા માટે, સર્વર દર 15 સેકન્ડે એક નાનો "ping" મોકલે છે.

Bug 1: જાગવાથી જીવંત stream મરી ગયો

બ્રાઉઝર જ્યારે પેજ ફરી દૃશ્યમાન થાય ત્યારે તેને જણાવે છે: tab બદલ્યા પછી, સ્ક્રીન અનલૉક થયા પછી. અમે તેને જોડાણ તપાસવાના સંકેત તરીકે વાપરતા — અને વ્યવહારમાં, stream રદ કરીને ફરી જોડાવા માટે, એમ માનીને કે તે છુપાયેલા રહેતાં મરી ગયો હશે.

ફોન અને embedded browsers પર, આ events stream મરી જાય તેના કરતાં ઘણી વધુ વાર ફાયર થાય છે — દરેક tab બદલવું, દરેક અનલૉક, અને કેટલાક embedded browsers માં દર થોડી સેકન્ડે. દરેક એ એક સંપૂર્ણ સ્વસ્થ stream ને રદ કર્યો. ચેટ ફરી જોડાયું, ફરી ચલાવ્યું, ફરી રદ થયું, અને "Connecting…" પર બેસી રહ્યું. પછી તેણે કહ્યું કે turn પૂરો થયો, જ્યારે agent હજી કામ કરી રહ્યો હતો.

ઉકેલ: stream બોલી રહ્યો છે કે નહીં તેના પરથી તેનો ન્યાય કરો

ચેટ હવે દરેક પ્રોજેક્ટના stream ને છેલ્લે ક્યારે કંઈ પણ મળ્યું તે રેકોર્ડ કરે છે — events અને 15-સેકન્ડના pings બંને. "ફરી દૃશ્યમાન" સંકેત ફક્ત તે stream ને રદ કરે છે જે 25 સેકન્ડથી શાંત રહ્યો હોય: ping અંતરાલ અને ધીમી network hop ના સરવાળા કરતાં લાંબું, તેથી જીવંત stream ક્યારેય લાયક ઠરતો નથી. Tests ચકાસે છે કે ping જીવંત હોવાની નિશાની ગણાય છે, અને જે stream હમણાં જ ping થયો હોય તેને મૃત ગણવામાં આવતો નથી.

આમાંથી લીધેલો નિયમ: પેજની દૃશ્યતા પેજ વિશે કંઈક કહે છે, નેટવર્ક જોડાણ વિશે નહીં. જોડાણને પૂછો.

Bug 2: ફોન જાગ્યા પછી અડધો જવાબ

આ એક અમે iOS simulator માં દર વખતે પુનઃઉત્પાદિત કરી શક્યા:

1. નવી ચેટ શરૂ કરો અને એક એવી વિનંતી મોકલો જે થોડો સમય લે.
2. બિલ્ડ દરમિયાન ફોનને સૂવા દો.
3. turn પૂરો થયા પછી અને બે-મિનિટનો replay buffer સમાપ્ત થયા પછી પાછા આવો.

ચેટે જવાબના પ્રથમ થોડા બ્લોક્સ બતાવ્યા, પૂરા થયેલા તરીકે ચિહ્નિત — અને પેજ refresh ન થાય ત્યાં સુધી તે એમ જ રહ્યું.

શા માટે

નવી ચેટમાં thread — એટલે કે સાચવેલી વાતચીત — ત્યાં સુધી હોતો નથી જ્યાં સુધી પહેલો સંદેશ તેને બનાવે નહીં. તે send function ની અંદર થાય છે, પછી કે send એ reconcile પગલું કેપ્ચર કરી લીધું હતું, જે હજી માનતું હતું કે કોઈ thread નથી. તેથી નવી ચેટમાં પ્રથમ turn ના અંતે, reconcile ને કોઈ thread દેખાયો નહીં અને તેણે કંઈ માંગ્યા વિના શાંતિથી પાછા ફરી ગયું.

સામાન્ય રીતે કોઈએ નોંધ્યું નહોતું, કારણ કે stream એ પણ આખો turn પહોંચાડી દીધો હતો. પરંતુ ફોન જે turn દરમિયાન સૂઈ ગયો હતો અને 120-સેકન્ડનો replay buffer સમાપ્ત થયા પછી પાછો આવ્યો, તે stream માંથી ખૂટતા events મેળવી શક્યો નહીં — અને જે reconcile ખૂટતું ભરવાનું હતું તે ક્યારેય ચાલ્યું જ નહોતું.

ઉકેલ

• Send reconcile ને કહે છે કે turn કયા thread નો છે, જેથી નવી ચેટના પ્રથમ turn ને બીજા કોઈપણ turn ની જેમ reconcile કરવામાં આવે. જો જવાબ પાછો આવે ત્યાં સુધીમાં તમે અલગ ચેટ ખોલી હોય, તો પરિણામ ખોટી જગ્યાએ બતાવવાને બદલે કાઢી નાખવામાં આવે છે.
• નિષ્ફળ reconcile ફરી પ્રયાસ થાય છે. ખરાબ connection પર જાગતો ફોન શોધી શકે કે turn પૂરો થઈ ગયો છે અને પછી તેને લાવવામાં નિષ્ફળ જાય. આ હવે યાદ રાખવામાં આવે છે, અને tab ફરી બતાવાય અથવા network પાછું આવે ત્યારે ચેટ ફરી પૂછે છે.
• "Worked for" પ્રમાણિક છે. દરેક જવાબ બતાવે છે કે agent કેટલો સમય કામ કરતો રહ્યો. જો tab ને સર્વરનો turn-ના-અંતનો સંદેશ ક્યારેય ન મળ્યો, તો તે પહેલાં પોતાની ઘડિયાળ પરથી તે ભરતો હતો — જે Send થી ફોન જાગે ત્યાં સુધી ચાલતી, વચ્ચેનો સમય સહિત. હવે તે આંકડો અંદાજ તરીકે ચિહ્નિત થાય છે, અને ઇતિહાસ આવે ત્યારે સંગ્રહાયેલી અવધિ દ્વારા બદલાય છે.

અમે શું શીખ્યા

• એ જ રીતે, એ જ ઉપકરણ પર ટેસ્ટ કરો જેનો લોકો ખરેખર ઉપયોગ કરે છે. બંને bugs "કામ કરતો stream" અને "ખિસ્સામાંનો ફોન" વચ્ચેના ગાળામાં રહેતા હતા.
• જે fallback ક્યારેય ચાલતું નથી તે fallback નથી. reconcile પગલું આ જ કિસ્સો પકડવા માટે હતું, અને તે ચુપચાપ છોડી દેવાતું હતું.
• Recovery ને પણ ફરી પ્રયાસ કરો. ફોન જાગે તે ક્ષણ ઘણીવાર તેના connection ની સૌથી ખરાબ ક્ષણ હોય છે.
• અનુમાનને હકીકત તરીકે ન બતાવો. ખોટી ઘડિયાળમાંથી મળેલી અવધિ કોઈ ન હોવા કરતાં ખરાબ છે; તેને લેબલ કરો અથવા બદલો.

આ કામે turn ચાલતી વખતે તમે જે જુઓ છો તેમાંની કેટલીક બાબતો પણ ટાપટીપ કરી: shell steps ને cd ને બદલે તે command થી લેબલ કરાય છે જે ખરેખર કામ કરે છે, chat માંના screenshots પેજનો ઉપલો-ડાબો ભાગ રાખે છે અને કૉલમમાં બંધબેસે છે, અને નવો પ્રોજેક્ટ refresh વગર તેનું જનરેટ થયેલું નામ લે છે.

જો તમે ફોન માટે તમારી પોતાની app બનાવતા હો, તો અમારી guides મોબાઇલ-ફ્રેન્ડલી વેબ app કેવી રીતે બનાવવી અને native vs progressive web apps મૂળભૂત બાબતો આવરી લે છે. ચેટ વિશે વધુ chat docs માં છે.