Condiciones de carrera en saldos y cupos

Casi todos los controles de saldo y de cupo siguen el mismo patrón: leer un valor, compararlo con un límite y, si cabe, escribir el nuevo valor. Entre la lectura y la escritura pasa tiempo, a veces unos milisegundos y a veces casi un segundo si en medio hay una llamada a otro servicio. Si en ese intervalo llega otra petición sobre el mismo saldo, las dos leen el mismo valor, las dos pasan la comprobación y las dos escriben.

MITRE llama a esto condición de carrera, CWE-362: ejecución concurrente sobre un recurso compartido sin la sincronización adecuada. Su caso más conocido tiene entrada propia, CWE-367, cuando lo que se comprobó ya no es cierto en el momento de usarlo. En la lógica de negocio aparece en saldos, cupos, inventario, cupones de un solo uso y cualquier límite que se cuenta.

Abre el laboratorio y lee BilleteraService.php en la carpeta mecato-carreras. Hay dos defectos que se suman: la lectura y la escritura están separadas por la llamada al antifraude, y el valor que se escribe se calcula con el saldo leído al principio, no con el que haya en ese momento. Luego lee registro-billetera.txt. Una carrera deja una huella reconocible: varias operaciones del mismo cliente, separadas por milisegundos, que leyeron exactamente el mismo saldo.

Como cada cobro escribe el saldo leído menos su monto, el último en escribir pisa a los demás: la billetera queda como si solo hubiera habido un cobro. Para medirlo, compara por cliente lo que se cobró con lo que bajó de verdad el saldo (el primer saldo leído del periodo menos el último saldo escrito). La diferencia es dinero que se gastó con la billetera sin salir de ella.

El mismo patrón aparece en FranjaService.php: contar los pedidos de la franja, comparar con el cupo y asignar. Lee registro-franjas.txt, donde cada asignación dice qué conteo leyó, y franjas-2026-11-08.txt, con el cierre del día.

Un arreglo que solo hace más pequeña la ventana (responder más rápido, quitar la llamada al antifraude) no la cierra: la carrera sigue ahí con menos probabilidad. Lo que la cierra es que la comprobación y la escritura sean una sola operación que la base de datos ejecuta sin que otra la interrumpa, o que la fila quede bloqueada mientras dura la transacción.