फोन झोपल्यावरही चॅट जिवंत ठेवणे
Mythex चा एजंट एका विनंतीवर मिनिटभर काम करू शकतो, आणि तुम्ही कदाचित फोनवरून पाहत असाल, जो काम सुरू असताना लॉक होतो, अॅप्स बदलतो आणि नेटवर्क बदलतो. दोन bugs यात चुकत होते. एकात, चॅट प्रत्येक “पेज पुन्हा दिसत आहे” signal ला त्याचे connection मेले असल्याचा पुरावा समजत होते, आणि “Connecting…” वर अडकून फिरत राहत होते. दुसऱ्यात, नवीन चॅटचे पहिले उत्तर फोन झोपलेला असताना आले होते, आणि परत आल्यावर चॅटला त्याचे फक्त पहिले काही तुकडे दिसत होते, मॅन्युअल refresh होईपर्यंत. दोन्ही दुरुस्त झाले आहेत.
चालू टर्नचा चॅट कसा मागोवा घेतो
एजंट काम करत असताना चॅट आमच्या सर्व्हरवरून एक stream उघडा ठेवते: प्रत्येक पायरी — एक विचार, एक tool call, उत्तराचा एक तुकडा — event म्हणून येतो. Stream तुटला तर चॅट पुन्हा कनेक्ट होते, आणि सर्व्हर अलीकडील events एका buffer मधून पुन्हा पाठवतो, जो शेवटचे 120 सेकंद धरतो. टर्न संपल्यावर चॅट सर्व्हरला साठवलेला इतिहास मागते आणि जे दाखवले होते त्याची जुळवणी साठवलेल्याशी करते. शेवटची ही पायरी stream ने चुकवलेले काहीही पकडते.
काहीही होत नसताना जिवंत connection आणि मेलेले connection यात फरक करण्यासाठी सर्व्हर दर 15 सेकंदांनी एक छोटा “ping” पाठवतो.
बग 1: जागे होणे एका निरोगी stream ला मारत होते
ब्राउझर पेजला सांगतात की ते पुन्हा दिसू लागले आहे: tab बदलल्यानंतर, screen अनलॉक झाल्यानंतर. आम्ही त्याचा उपयोग connection तपासण्याचा संकेत म्हणून करत होतो — आणि व्यवहारात stream abort करून पुन्हा कनेक्ट करत होतो, असे गृहीत धरून की ते लपलेले असताना मेले.
फोनवर आणि embedded browsers मध्ये हे events stream मरण्यापेक्षा खूप वेळा येतात — प्रत्येक tab बदलणे, प्रत्येक अनलॉक, आणि काही embedded browsers मध्ये दर काही सेकंदाला. प्रत्येक जण एका पूर्णपणे निरोगी stream ला abort करत होता. चॅट पुन्हा कनेक्ट होत होते, replay होत होते, पुन्हा abort होत होते, आणि शेवटी “Connecting…” वर बसत होते. मग ते म्हणायचे की एजंट अजून काम करत असताना टर्न संपला.
उपाय: stream बोलतो आहे का त्यावरून ठरवा
चॅट आता प्रत्येक प्रोजेक्टचा stream शेवटी काहीही कधी मिळाले ते नोंदवते — events आणि 15-सेकंदाचे pings दोन्ही. “पुन्हा दिसत आहे” signal फक्त तो stream abort करतो जो 25 सेकंद शांत होता: ping interval आणि एका संथ नेटवर्क hop यांच्यापेक्षा जास्त, त्यामुळे जिवंत stream कधीच पात्र ठरत नाही. चाचण्या तपासतात की ping हे जिवंत असण्याचे चिन्ह म्हणून मोजले जाते, आणि नुकताच ping केलेला stream मेला असे मानले जात नाही.
यातून घेतलेला नियम: पेज दिसणे हे पेजबद्दल काहीतरी सांगते, नेटवर्क connection बद्दल नाही. Connection लाच विचारा.
बग 2: फोन जागा झाल्यावर अर्धे उत्तर
हा बग आम्ही iOS simulator मध्ये प्रत्येक वेळी पुनरुत्पादित करू शकलो:
- नवीन चॅट सुरू करा आणि थोडा वेळ लागणारी विनंती पाठवा.
- बिल्ड चालू असताना फोन झोपू द्या.
- टर्न संपल्यावर आणि दोन मिनिटांचा replay buffer संपल्यावर परत या.
चॅट उत्तराचे पहिले काही blocks दाखवत होते, पूर्ण झालेले म्हणून चिन्हांकित — आणि पेज refresh होईपर्यंत तसेच राहत होते.
का
नवीन चॅटला पहिला संदेश तयार होईपर्यंत thread — म्हणजे साठवलेले संभाषण — नसते. ते send function च्या आत होते, नंतर, आणि send ने जुळवणीची पायरी आधीच पकडून ठेवली होती, जी अजूनही मानत होती की thread नाहीये. त्यामुळे नवीन चॅटच्या पहिल्या टर्नच्या शेवटी जुळवणीला thread दिसला नाही आणि ते काहीही न मागता शांतपणे परत आले.
सहसा कोणाच्या लक्षात येत नसे, कारण stream ने संपूर्ण टर्न आधीच पाठवलेला असे. पण जो फोन टर्नदरम्यान झोपला होता आणि 120-सेकंदांचा replay buffer संपल्यानंतर परत आला, त्याला stream मधून हरवलेले events मिळू शकत नव्हते — आणि ती भरणारी जुळवणी कधीच चालली नव्हती.
उपाय
- Send जुळवणीला सांगते की टर्न कोणत्या thread चा आहे, त्यामुळे नवीन चॅटच्या पहिल्या टर्नची इतर कोणत्याही प्रमाणे जुळवणी होते. उत्तर परत येईपर्यंत तुम्ही दुसरी चॅट उघडली असेल तर निकाल चुकीच्या जागी न दाखवता टाकला जातो.
- अयशस्वी जुळवणी पुन्हा प्रयत्न केली जाते. खराब नेटवर्कवर जागा झालेला फोन टर्न संपलेला पाहू शकतो आणि तो आणताना अयशस्वी होऊ शकतो. ते आता लक्षात ठेवले जाते, आणि पेज पुन्हा दिसल्यावर किंवा नेटवर्क परत आल्यावर चॅट पुन्हा विचारते.
- “Worked for” प्रामाणिक आहे. प्रत्येक उत्तर एजंटने किती वेळ काम केले ते दाखवते. Tab ने सर्व्हरचा शेवटचा संदेश कधीच पाहिला नसेल तर ते आपल्या स्वतःच्या घड्याळावरून भरत असे — जे Send पासून फोन जागा होईपर्यंत चालत होते, दूर असलेला वेळ धरून. तो आकडा आता अंदाज म्हणून चिन्हांकित आहे, आणि इतिहास आल्यावर साठवलेल्या कालावधीने बदलला जातो.
आम्ही काय शिकलो
- लोक प्रत्यक्षात वापरतात त्या उपकरणावर, त्या पद्धतीने चाचणी करा. दोन्ही बग “काम करणारा stream” आणि “खिशातला फोन” यांच्या मधल्या जागेत राहत होते.
- न चालणारा fallback म्हणजे fallback नाही. जुळवणीची पायरी नेमकी हीच केस पकडण्यासाठी होती, आणि ती शांतपणे वगळली जात होती.
- Recovery ची सुद्धा पुन्हा प्रयत्न करा. फोन जागा होतो ठीक त्याच क्षणी त्याचे connection सहसा सर्वात वाईट असते.
- अंदाज तथ्य म्हणून दाखवू नका. चुकीच्या घड्याळावरून आलेला कालावधी काहीच नसण्यापेक्षा वाईट आहे; त्यावर लेबल लावा किंवा बदला.
त्याच कामाने टर्न चालताना तुम्हाला दिसणाऱ्या काही गोष्टीही नीटनेटक्या केल्या: shell पायऱ्या cd ऐवजी त्या कामाच्या command ने लेबल होतात, चॅटमधील screenshots पेजचा वरचा-डावा भाग ठेवतात आणि स्तंभात बसतात, आणि नवीन प्रोजेक्ट refresh न करता त्याचे तयार झालेले नाव घेतो.
तुम्ही फोनसाठी स्वतःचे अॅप बनवत असाल तर mobile-friendly web अॅप कसे बनवायचे आणि native विरुद्ध progressive web apps या guides मध्ये मूलभूत गोष्टी आहेत. चॅटबद्दल अधिक chat docs मध्ये आहे.