ဖုန်း အိပ်သွားရင် chat ကို အသက်ရှင်နေအောင် ထိန်းခြင်း

Mythex ရဲ့ agent က တစ်ခုတည်းသော request အတွက် မိနစ်အတော်ကြာ အလုပ်လုပ်နိုင်ပြီး၊ သင်က ဖုန်းကနေ ကြည့်နေနိုင်ပါတယ်– ဖုန်းက လော့ခ်ကျတယ်၊ အက်ပ် ပြောင်းတယ်၊ network ပြောင်းတယ်။ bug နှစ်ခုက ဒါကို ပျက်စီးစေပါတယ်။ တစ်ခုက chat က "စာမျက်နှာ မြင်ရပြီ" signal တိုင်းကို ချိတ်ဆက်မှု သေသွားလို့ ယူဆပြီး "Connecting…" မှာ ဆက်ပတ်နေတာ ဖြစ်ပါတယ်။ နောက်တစ်ခုက ဖုန်း အိပ်ပျော်ပြီး စကားဝိုင်းသစ်ရဲ့ ပထမ ပြန်ကြားချက်ကို လွဲသွားတဲ့အခါ၊ ပြန်ရောက်တော့ အစပိုင်း အပိုင်းအစအနည်းငယ်သာ ပေါ်တာ၊ refresh မလုပ်မချင်း ဖြစ်ပါတယ်။ နှစ်ခုလုံး ပြင်ပြီးပါပြီ။

Chat က ရှိနေတဲ့ turn ကို ဘယ်လို လိုက်ပါလဲ

agent လုပ်နေစဉ် chat က ဆာဗာဆီက stream တစ်ခုကို ဖွင့်ထားပါတယ်– အဆင့်တစ်ခုစီ၊ စဉ်းစားချက်၊ tool ခေါ်ဆိုမှု၊ ပြန်ကြားချက်အပိုင်းအစ– event အဖြစ် ရောက်လာပါတယ်။ stream ပျက်သွားရင် chat က ပြန်ချိတ်ပြီး ဆာဗာက နောက်ဆုံး ၁၂၀ စက္ကန့် buffer ထဲက event တွေကို ပြန်ဖွင့်ပေးပါတယ်။ turn ပြီးတဲ့အခါ chat က သိမ်းထားတဲ့ သမိုင်းကိုလည်း ဆာဗာကနေ ပြန်တောင်းပြီး ပြသထားတာနဲ့ ယှဉ်ကြည့်ပါတယ်။ ဒီအဆင့်က stream က လွတ်သွားတာကို ဖမ်းပါတယ်။

ဘာမှ မဖြစ်နေတဲ့အချိန်မှာ ချိတ်ဆက်မှု အသက်ရှင်နေလား သေနေလား သိဖို့ ဆာဗာက စက္ကန့် ၁၅ တိုင်း "ping" အသေးလေး ပို့ပါတယ်။

Bug ၁– နိုးလာတာနဲ့ ကျန်းမာနေတဲ့ stream ပြတ်သွားခြင်း

ဘရောက်ဇာတွေက စာမျက်နှာ ပြန်မြင်ရတဲ့အခါ ပြောပါတယ်– tab ပြောင်းပြီးနောက်၊ screen လော့ခ်ဖွင့်ပြီးနောက်။ ကျွန်တော်တို့က အဲဒါကို ချိတ်ဆက်မှု စစ်ဖို့ အချက်ပေးအဖြစ် သုံးခဲ့ပြီး၊ လက်တွေ့မှာ stream ကို ဖြတ်ပြီး ပြန်ချိတ်တာ၊ ဖျောက်ထားစဉ် သေသွားတယ် လို့ ယူဆခဲ့ပါတယ်။

ဖုန်းတွေနဲ့ embedded browser တွေမှာ ဒီ event တွေက stream သေတာထက် ပိုမကြာခဏ ဖြစ်ပါတယ်– tab ပြောင်းတိုင်း၊ လော့ခ်ဖွင့်တိုင်း၊ အချို့ embedded browser တွေမှာဆို စက္ကန့် အနည်းငယ်တိုင်း။ တစ်ခုချင်းစီက ကျန်းမာတဲ့ stream ကို ဖြတ်ခဲ့ပါတယ်။ chat က ပြန်ချိတ်၊ ပြန်ဖွင့်၊ နောက်တစ်ခါ ဖြတ်၊ နောက်ဆုံး "Connecting…" မှာ ရပ်နေခဲ့ပါတယ်။ ပြီးတော့ agent လုပ်နေဆဲမှာတင် turn ပြီးသွားပြီလို့ ပြောခဲ့ပါတယ်။

ပြင်ဆင်ချက်– stream က စကားပြောနေသလားကို ကြည့်ပါ

chat က project တစ်ခုစီရဲ့ stream ဟာ နောက်ဆုံး ဘာရလဲ၊ event တွေနဲ့ 15 စက္ကန့် ping တွေ နှစ်ခုလုံးအတွက် မှတ်ထားပါတယ်။ "ပြန်မြင်ရပြီ" signal က stream တစ်ခုကို ၂၅ စက္ကန့် တိတ်ဆိတ်နေမှသာ ဖြတ်ပါတယ်– ping interval နဲ့ network နှေးကွေးမှု အနည်းငယ် ပေါင်းထားတာ၊ ဒါကြောင့် အသက်ရှင်နေတဲ့ stream ဘယ်တော့မှ ဒီအခြေအနေ မရောက်ပါဘူး။ ping တစ်ခုက အသက်ရှင်ကြောင်း သက်သေ ဖြစ်တယ်၊ လတ်တလော ping ပို့ထားတဲ့ stream ကို သေနေတယ်လို့ မယူဆပါဘူး ဆိုတာ စမ်းသပ်ချက်တွေက စစ်ပါတယ်။

သင်ယူလိုက်တဲ့ စည်းမျဉ်း– စာမျက်နှာ မြင်ရခြင်းက စာမျက်နှာအကြောင်း ပြောတာ ဖြစ်ပြီး network ချိတ်ဆက်မှု အကြောင်း မဟုတ်ပါဘူး။ ချိတ်ဆက်မှုကိုသာ မေးပါ။

Bug ၂– ဖုန်း နိုးပြီးနောက် တစ်ဝက်တစ်ပျက် ပြန်ကြားချက်

ဒါကို iOS simulator မှာ အမြဲ ပြန်ဖန်တီးလို့ ရခဲ့ပါတယ်–

1. စကားဝိုင်းအသစ် တစ်ခု စတင်ပြီး အချိန်ကြာတဲ့ request တစ်ခု ပို့ပါ။
2. တည်ဆောက်နေစဉ် ဖုန်းကို အိပ်ခိုင်းထားပါ။
3. turn ပြီးပြီး replay buffer ၂ မိနစ် ကုန်ပြီးနောက် ပြန်လာပါ။

chat က ပြန်ကြားချက်ရဲ့ ပထမ block အနည်းငယ်ကို ပြီးပြီလို့ ပြပြီး၊ စာမျက်နှာ refresh မလုပ်မချင်း အဲဒီအတိုင်း ရပ်နေခဲ့ပါတယ်။

အကြောင်းရင်း

စကားဝိုင်းသစ်မှာ ပထမ message ဖန်တီးတဲ့အထိ thread (သိမ်းထားတဲ့ စကားဝိုင်း) မရှိပါဘူး။ အဲဒါက send function အတွင်းမှာ ဖြစ်ပြီး၊ send က reconcile step ကို အရင်ယူထားပြီးသား ဖြစ်ပါတယ်၊ ထို reconcile က thread မရှိသေးဘူးလို့ ထင်နေဆဲပါ။ ဒါကြောင့် စကားဝိုင်းသစ်ရဲ့ turn ပထမအဆုံးမှာ reconcile က thread မတွေ့ပြီး တိတ်ဆိတ်စွာ ပြန်သွားပါတယ်။

အများအားဖြင့် ဘယ်သူမှ မသတိထားမိပါဘူး၊ ဘာလို့လဲဆို stream က turn တစ်ခုလုံးကို ပို့ပြီးသားမို့ပါ။ ဒါပေမယ့် ဖုန်း အိပ်ပြီး turn ပြီးချိန် replay buffer ၁၂၀ စက္ကန့် ကုန်သွားမှ ပြန်လာရင် stream ကနေ ပျောက်သွားတဲ့ event တွေ ရမရနိုင်ပါ။ ဖြည့်ပေးရမယ့် reconcile က ဘယ်တော့မှ မလုပ်ခဲ့ပါဘူး။

ပြင်ဆင်ချက်

• Send က reconcile ကို turn ဘယ် thread နဲ့ ဆိုင်လဲ ပြောပြပါတယ်၊ ဒါကြောင့် စကားဝိုင်းသစ်ရဲ့ ပထမ turn ကလည်း တခြား turn လိုပဲ reconcile လုပ်ပါတယ်။ ဖြေဆိုချက် ပြန်လာချိန်မှာ တခြား စကားဝိုင်းကို ဖွင့်ထားရင် ရလဒ်ကို မှားတဲ့နေရာမှာ မပြဘဲ ချန်ထားပါတယ်။
• reconcile မအောင်မြင်ရင် ထပ်ကြိုးစားပါတယ်။ ချိတ်ဆက်မှု မကောင်းတဲ့ အခြေအနေမှာ ဖုန်း နိုးတဲ့အခါ turn ပြီးသွားပြီဖြစ်နေပြီး သမိုင်းကို ယူလို့ မရနိုင်ပါ။ အဲဒါကို အခု မှတ်ထားပြီး tab ပြန်မြင်ရတဲ့အခါ ဒါမှမဟုတ် network ပြန်ရလာတဲ့အခါ chat က ထပ်မေးပါတယ်။
• "Worked for" ကို ရိုးသားစွာ ပြပါတယ်။ ပြန်ကြားချက်တိုင်းမှာ agent ဘယ်လောက်ကြာအောင် အလုပ်လုပ်ခဲ့လဲ ပြပါတယ်။ tab က ဆာဗာရဲ့ turn-ပြီး message ကို မမြင်ခဲ့ရင် ယခင်က မိမိ နာရီကနေ ဖြည့်ခဲ့ပါတယ်၊ ၎င်းက Send ကနေ ဖုန်း နိုးတဲ့အထိ ကြာခဲ့တဲ့ အချိန်ကို ပါစေပါတယ်။ အဲဒီ ကိန်းကို အခန်းဖြစ်ကြောင်း ရေးပြထားပြီး သမိုင်း ရောက်လာချိန်မှာ သိမ်းထားတဲ့ ကြာချိန်နဲ့ အစားထိုးပါတယ်။

ဒီကနေ ရလာတာတွေ

• လူတွေ အမှန်တကယ် သုံးတဲ့ စက်ပေါ်မှာ၊ သူတို့ သုံးတဲ့ပုံစံအတိုင်း စမ်းပါ။ bug နှစ်ခုစလုံး "အလုပ်လုပ်တဲ့ stream" နဲ့ "ဖုန်း ဘောင်းဘီအိတ်ထဲ" ကြားက ကွာဟချက်မှာ ရှိခဲ့ပါတယ်။
• တစ်ခါမှ မလုပ်တဲ့ fallback က fallback မဟုတ်ပါ။ reconcile က ဒီလိုကိစ္စကို ဖမ်းဖို့ ရှိခဲ့ပေမယ့် တိတ်ဆိတ်စွာ ကျော်သွားခဲ့ပါတယ်။
• ပြန်ကောင်းအောင် လုပ်တာကိုလည်း ထပ်ကြိုးစားပါ။ ဖုန်း နိုးတဲ့ အချိန်က ချိတ်ဆက်မှု အဆိုးဆုံး ဖြစ်တတ်တဲ့အချိန် ဖြစ်တတ်ပါတယ်။
• ခန့်မှန်းချက်ကို အမှန်အဖြစ် မပြပါနဲ့။ မှားတဲ့ နာရီကနေ ယူထားတဲ့ ကြာချိန်က မရှိတာထက်ဆိုးပါတယ်၊ အမှတ်အသား ထည့်ပါ သို့မဟုတ် အစားထိုးပါ။

အဲဒီ အလုပ်က turn တစ်ခု run နေစဉ် မြင်ရမယ့် အရာအချို့ကိုလည်း သန့်စင်ခဲ့ပါတယ်– shell အဆင့်တွေကို cd အစား အလုပ်လုပ်ပေးတဲ့ command နဲ့ အမည်ပေးထားပြီး၊ chat ထဲက screenshot တွေက စာမျက်နှာရဲ့ ဘယ်ဘက်ထိပ်ကို ထိန်းထားပြီး column နဲ့ ကိုက်ညီပါတယ်၊ ပရောဂျက်အသစ်က refresh မလုပ်ဘဲ ထုတ်ပေးတဲ့ နာမည်ကို ရပါတယ်။

ဖုန်းအတွက် အက်ပ်တည်ဆောက်ဖို့ သင့်ကိုယ်ပိုင် နည်းပညာ အခြေခံတွေကို mobile-friendly web app တည်ဆောက်နည်း နဲ့ native နဲ့ progressive web app ကွာခြားချက် မှာ ရှိပါတယ်။ chat အကြောင်းကို chat docs မှာ ကြည့်ပါ။