தொலைபேசி தூங்கும்போது chat-ஐ உயிருடன் வைத்திருத்தல்

Mythex-இன் agent ஒரு கோரிக்கையில் நிமிடங்களுக்கு வேலை செய்யலாம்; நீங்கள் ஒரு தொலைபேசியிலிருந்து பார்த்துக்கொண்டிருக்கலாம் — அது வேலை செய்யும்போதே பூட்டப்படும், app-களை மாற்றும், network-ஐ மாற்றும். இரண்டு பிழைகள் அதை தவறாக்கின. ஒன்றில், “பக்கம் மீண்டும் தெரிகிறது” என்ற ஒவ்வொரு சமிக்ஞையையும் chat தன் இணைப்பு இறந்துவிட்டது என்ற ஆதாரமாக எடுத்தது; “Connecting…” என்பதில் சுழன்றது. மற்றொன்றில், ஒரு புதிய chat-இன் முதல் பதிலை தொலைபேசி தூங்கியபோது தவறவிட்டது; கைமுறையாக மீண்டும் ஏற்றும் வரை அது முதல் சில பகுதிகளை மட்டுமே காட்டியது. இரண்டும் சரிசெய்யப்பட்டுள்ளன.

chat ஓடும் turn-ஐ எப்படிப் பின்தொடர்கிறது

Agent வேலை செய்யும்போது, chat எங்கள் சேவையகங்களிலிருந்து ஒரு stream-ஐத் திறந்து வைத்திருக்கிறது: ஒவ்வொரு படியும் — ஒரு சிந்தனை, ஒரு கருவி அழைப்பு, பதிலின் ஒரு பகுதி — ஒரு நிகழ்வாக வருகிறது. Stream துண்டிக்கப்பட்டால், chat மீண்டும் இணைகிறது; சேவையகம் கடந்த 120 வினாடிகளை வைத்திருக்கும் buffer-இலிருந்து சமீபத்திய நிகழ்வுகளை மீண்டும் அனுப்புகிறது. Turn முடிந்ததும், chat சேமிக்கப்பட்ட வரலாற்றையும் சேவையகத்திடம் கேட்டு, அது காட்டியதையும் சேமித்ததையும் ஒப்பிடுகிறது. அந்தக் கடைசிப் படி stream தவறவிட்டதைப் பிடிக்கிறது.

எதுவும் நடக்காதபோது உயிருள்ள இணைப்பையும் இறந்த இணைப்பையும் வேறுபடுத்த, சேவையகம் ஒவ்வொரு 15 வினாடிக்கும் ஒரு சிறிய “ping” அனுப்புகிறது.

பிழை 1: விழித்தெழுதல் ஒரு ஆரோக்கியமான stream-ஐக் கொன்றது

பக்கம் மீண்டும் தெரியும்போது உலாவிகள் பக்கத்துக்குச் சொல்கின்றன: tab மாற்றிய பின், திரை திறந்த பின். அதை இணைப்பைச் சரிபார்க்கும் குறிப்பாக நாங்கள் பயன்படுத்தினோம் — நடைமுறையில், stream-ஐ நிறுத்தி மீண்டும் இணைக்க, அது மறைந்திருந்தபோது இறந்திருக்கும் என்று கருதி.

தொலைபேசிகளிலும் உட்பொதிந்த உலாவிகளிலும் இந்த நிகழ்வுகள் stream இறப்பதைவிட மிக அடிக்கடி நிகழ்கின்றன — ஒவ்வொரு tab மாற்றமும், ஒவ்வொரு திறப்பும், சில உட்பொதிந்த உலாவிகளில் ஒவ்வொரு சில வினாடிகளுக்கும். ஒவ்வொன்றும் ஆரோக்கியமான ஒரு stream-ஐ நிறுத்தியது. Chat மீண்டும் இணைந்தது, மீண்டும் இயக்கியது, மீண்டும் நிறுத்தப்பட்டது, இறுதியில் “Connecting…” என்பதில் அமர்ந்தது. பின்னர் agent இன்னும் வேலை செய்துகொண்டிருந்தபோதே turn முடிந்துவிட்டது என்றது.

தீர்வு: stream பேசுகிறதா என்பதை வைத்து மதிப்பிடு

Chat இப்போது ஒவ்வொரு project-இன் stream கடைசியாக எதையாவது — நிகழ்வுகளையும் 15 வினாடி pings-ஐயும் — எப்போது பெற்றது என்பதைப் பதிவு செய்கிறது. “மீண்டும் தெரிகிறது” சமிக்ஞை 25 வினாடிகள் அமைதியாக இருந்த stream-ஐ மட்டுமே நிறுத்துகிறது: ping இடைவெளியும் மெதுவான network hop-உம் சேர்ந்ததை விட நீண்டது, அதனால் உயிருள்ள stream ஒருபோதும் தகுதி பெறாது. Ping ஒரு உயிர் அறிகுறியாக எண்ணப்படுகிறது என்றும், சமீபத்தில் ping அனுப்பிய stream இறந்ததாக நடத்தப்படுவதில்லை என்றும் சோதனைகள் சரிபார்க்கின்றன.

இதிலிருந்து எடுத்த விதி: பக்கத்தின் தெரிவு நிலை பக்கத்தைப் பற்றியது, network இணைப்பைப் பற்றியது அல்ல. இணைப்பிடம் கேளுங்கள்.

பிழை 2: தொலைபேசி விழித்த பின் பாதி பதில்

இதை iOS simulator-இல் ஒவ்வொரு முறையும் மீண்டும் உருவாக்க முடிந்தது:

1. புதிய chat-ஐத் தொடங்கி, நேரம் எடுக்கும் ஒரு கோரிக்கையை அனுப்புங்கள்.
2. Build முழுவதும் தொலைபேசி தூங்க விடுங்கள்.
3. Turn முடிந்து, இரண்டு நிமிட replay buffer காலாவதியான பிறகு திரும்புங்கள்.

Chat பதிலின் முதல் சில பகுதிகளை முடிந்தவையாகக் காட்டியது — அவை பக்கத்தை மீண்டும் ஏற்றும் வரை அப்படியே இருந்தன.

ஏன்

புதிய chat-க்கு முதல் message ஒரு தொடர் (thread) உருவாக்கும் வரை — அதாவது சேமிக்கப்பட்ட உரையாடல் — தொடர் இல்லை. அது send function உள்ளே நடக்கிறது; send ஏற்கனவே reconcile படியைக் கைப்பற்றிய பிறகு, அது இன்னும் தொடர் இல்லை என்று நினைத்தது. ஆகவே ஒரு புதிய chat-இல் முதல் turn முடிவில், reconcile தொடர் எதையும் பார்க்கவில்லை; எதையும் கேட்காமல் அமைதியாகத் திரும்பியது.

பொதுவாக யாரும் கவனிக்கவில்லை, ஏனெனில் stream முழு turn-ஐயும் ஏற்கனவே கொடுத்திருந்தது. ஆனால் turn நடக்கும்போது தூங்கி, replay buffer காலாவதியான பின் திரும்பிய தொலைபேசியால் stream-இலிருந்து விடுபட்ட நிகழ்வுகளைப் பெற முடியவில்லை — அந்த இடைவெளியை நிரப்ப வேண்டிய reconcile ஒருபோதும் ஓடவில்லை.

தீர்வு

• Send, எந்தத் தொடர் அந்த turn-க்குச் சொந்தம் என்பதை reconcile-க்குச் சொல்கிறது, அதனால் புதிய chat-இன் முதல் turn மற்ற எந்த turn-ஐப் போலவும் reconcile செய்யப்படுகிறது. பதில் வரும்போது நீங்கள் வேறு chat-ஐத் திறந்திருந்தால், முடிவு தவறான இடத்தில் காட்டப்படாமல் கைவிடப்படுகிறது.
• தோல்வியடைந்த reconcile மீண்டும் முயற்சிக்கப்படும். மோசமான இணைப்பில் விழிக்கும் தொலைபேசி, turn முடிந்துவிட்டதைக் கண்டு அதைப் பெறத் தவறலாம். அது இப்போது நினைவில் வைக்கப்படுகிறது; tab மீண்டும் காட்டப்படும்போதோ network திரும்பும்போதோ chat மீண்டும் கேட்கும்.
• “Worked for” நேர்மையானது. ஒவ்வொரு பதிலும் agent எவ்வளவு நேரம் வேலை செய்தது என்று காட்டுகிறது. Tab சேவையகத்தின் turn-முடிவுச் செய்தியைப் பார்க்கவில்லை என்றால், முன்பு அது தன் சொந்த கடிகாரத்திலிருந்து — Send அழுத்தியதிலிருந்து தொலைபேசி விழிக்கும் வரை, நீங்கள் விலகியிருந்த நேரமும் சேர்த்து — நிரப்பியது. அந்த எண் இப்போது மதிப்பீடு எனக் குறிக்கப்படுகிறது; வரலாறு வந்ததும் சேமிக்கப்பட்ட கால அளவால் மாற்றப்படுகிறது.

நாங்கள் கற்றது

• மக்கள் பயன்படுத்தும் சாதனத்தில், அவர்கள் பயன்படுத்தும் விதத்திலேயே சோதியுங்கள். இரண்டு பிழைகளும் “வேலை செய்யும் stream” மற்றும் “பாக்கெட்டில் உள்ள தொலைபேசி” என்ற இடைவெளியில் இருந்தன.
• ஒருபோதும் இயங்காத பின்னடைவு வழி ஒரு பின்னடைவு வழி அல்ல. Reconcile படி சரியாக இந்த நிலையைப் பிடிக்கவே இருந்தது; அது அமைதியாகத் தவிர்க்கப்பட்டது.
• மீட்புக்கும் மீண்டும் முயற்சி வேண்டும். தொலைபேசி விழிக்கும் தருணம்தான் அதன் இணைப்பு மிக மோசமாக இருக்கும் நேரம் ஆகக்கூடும்.
• ஊகத்தை உண்மையாகக் காட்டாதீர்கள். தவறான கடிகாரத்திலிருந்து வரும் கால அளவு எதுவுமே இல்லாததைவிட மோசம்; அதைக் குறியிடுங்கள் அல்லது மாற்றுங்கள்.

அதே வேலை turn ஓடும்போது நீங்கள் பார்க்கும் சில விஷயங்களையும் ஒழுங்குபடுத்தியது: shell படிகள் cd அல்ல, வேலையைச் செய்யும் command-இன் பெயரால் பெயரிடப்படுகின்றன; chat-இல் உள்ள screenshots பக்கத்தின் மேல் இடதுபுறத்தை வைத்து நெடுவரிசைக்குள் பொருந்துகின்றன; புதிய project பக்கத்தை மீண்டும் ஏற்றாமல் அதன் உருவாக்கப்பட்ட பெயரைப் பெறுகிறது.

தொலைபேசிகளுக்கான சொந்த app-ஐ உருவாக்கினால், மொபைலுக்கு ஏற்ற web app உருவாக்குவது எப்படி மற்றும் native மற்றும் progressive web apps வழிகாட்டிகள் அடிப்படைகளை விளக்குகின்றன. Chat பற்றிய மேலும் விவரங்கள் chat docs-இல் உள்ளன.