¿Qué causa una condición de carrera y cómo encuentras una que solo aparece en producción?

Una condición de carrera ocurre cuando dos hilos o peticiones tocan estado mutable compartido y el resultado depende del momento. La forma clásica es leer, modificar y escribir sin mantener un lock durante los tres pasos. Para encontrar una en producción, busca estado que se comprueba y luego se usa, añade logging correlacionado alrededor de esa secuencia, reproduce bajo concurrencia real en vez de en un test unitario, y deja que las restricciones de la base de datos pillen la violación.

Una carrera necesita dos cosas: estado mutable compartido y dos caminos llegando a la vez. Casi todas las que he depurado tienen la misma forma, una comprobación seguida de una acción con un hueco en medio. Lee el saldo, decide que es suficiente, escribe el saldo nuevo. Dos peticiones se intercalan y el número está mal. Encontrarlas en producción va sobre todo de aceptar que no vas a llegar a una reproducción a base de clics. Escribo un script que lanza la misma petición un par de cientos de veces en paralelo, porque la ventana puede ser de dos milisegundos. Después registro con un id de petición a ambos lados de la lectura y de la escritura, para ver el entrelazado en la línea temporal. Para el arreglo intento mover el invariante a la base de datos en vez de a la aplicación: un update con un where sobre el valor esperado, o una restricción única, para que lo imponga la base de datos. Los locks a nivel de aplicación solo funcionan si todos los escritores pasan por tu código, y tarde o temprano uno no lo hará.