Qu'est-ce qui cause une condition de concurrence, et comment trouvez-vous celle qui n'apparaît qu'en production ?

Une condition de concurrence se produit quand deux threads ou requêtes touchent un état mutable partagé et que le résultat dépend du timing. La forme classique, c'est lire, modifier, écrire sans tenir un verrou sur les trois étapes. Pour en trouver une en production, cherchez un état qui est vérifié puis utilisé, ajoutez des logs corrélés autour de cette séquence, reproduisez sous une vraie concurrence plutôt que dans un test unitaire, et laissez les contraintes de la base attraper la violation.

Une course a besoin de deux choses : un état mutable partagé, et deux chemins qui l'atteignent en même temps. Presque toutes celles que j'ai déboguées ont la même forme, une vérification suivie d'une action avec un écart entre les deux. Lire le solde, décider qu'il est suffisant, écrire le nouveau solde. Deux requêtes s'entrelacent et le chiffre est faux. Les trouver en production, c'est surtout accepter qu'on ne peut pas cliquer jusqu'à une reproduction. J'écris un script qui envoie la même requête deux cents fois en parallèle, parce que la fenêtre fait peut-être deux millisecondes. Ensuite je logue avec un identifiant de requête de part et d'autre de la lecture et de l'écriture, pour voir l'entrelacement dans la chronologie. Pour le correctif, j'essaie de déplacer l'invariant dans la base plutôt que dans l'appli : un update avec une clause where sur la valeur attendue, ou une contrainte d'unicité, pour que la base l'impose. Les verrous au niveau applicatif ne marchent que si tous les écrivains passent par votre code, et un jour l'un d'eux ne le fera pas.