Wodurch entsteht eine Race Condition, und wie findest du eine, die nur in Produktion auftaucht?

Eine Race Condition entsteht, wenn zwei Threads oder Requests geteilten veränderlichen State anfassen und das Ergebnis vom Timing abhängt. Die klassische Form ist read, modify, write, ohne über alle drei Schritte hinweg ein Lock zu halten. Um eine in Produktion zu finden, such nach State, der geprüft und dann verwendet wird, ergänz korrelierte Logs rund um diese Sequenz, reproduzier unter echter Nebenläufigkeit statt in einem Unit Test, und lass Datenbank-Constraints die Verletzung abfangen.

Eine Race braucht zwei Dinge: geteilten veränderlichen State und zwei Pfade, die ihn gleichzeitig erreichen. Fast jede, die ich debuggt habe, hat dieselbe Form, eine Prüfung gefolgt von einer Aktion, mit einer Lücke dazwischen. Saldo lesen, entscheiden dass er reicht, neuen Saldo schreiben. Zwei Requests verschränken sich und die Zahl stimmt nicht. Sie in Produktion zu finden heißt vor allem zu akzeptieren, dass du dich nicht zu einer Reproduktion klicken kannst. Ich schreibe ein Skript, das denselben Request ein paar hundert Mal gleichzeitig abfeuert, weil das Fenster vielleicht zwei Millisekunden breit ist. Dann logge ich mit einer Request-id vor und nach dem Read und dem Write, damit ich die Verschränkung in der Zeitachse sehe. Für den Fix versuche ich, die Invariante in die Datenbank zu verlegen statt in die App: ein Update mit einer where-Klausel auf den erwarteten Wert oder ein Unique Constraint, damit die Datenbank es durchsetzt. Locks auf Anwendungsebene funktionieren nur, wenn jeder Writer durch deinen Code geht, und irgendwann tut es einer nicht.