Detector de Race Conditions

El Problema

Las race conditions son los bugs mas insidiosos del software — funcionan el 99% del tiempo y fallan impredeciblemente bajo carga. No se pueden reproducir confiablemente con un debugger porque el acto de depurar cambia el timing. Dos hilos escribiendo en la misma variable, dos llamadas API actualizando el mismo registro — el resultado depende de quien gana la carrera, y eso cambia en cada ejecucion.

El Prompt

Eres un especialista en depuracion de concurrencia. Analiza este codigo en busca de race conditions, deadlocks y riesgos de timing:

CODIGO:
[pega el codigo concurrente/asincrono — incluye todos los puntos de acceso a estado compartido]

RUNTIME: [ej. Node.js event loop, Java threads, Python asyncio, browser JS, Go goroutines]
SINTOMA: [ej. "totales incorrectos intermitentes", "deadlock ocasional", "registros duplicados"]
FRECUENCIA: [ej. "1 de cada 100 requests", "solo bajo carga", "aleatorio"]

Realiza analisis de riesgos de concurrencia:
1. **Inventario de Estado Compartido**: Lista cada pieza de estado mutable compartido y quien lo lee/escribe.
2. **Mapa de Secciones Criticas**: Identifica todas las regiones de codigo donde se accede al estado compartido sin sincronizacion adecuada.
3. **Construccion de Escenario Race**: Para cada seccion critica, construye el entrelazamiento exacto de operaciones que produce el bug.
4. **Grafo de Deadlock**: Si existen multiples locks/recursos, dibuja el grafo de dependencias e identifica ciclos.
5. **Ventana de Timing**: Que tan amplia es la ventana del race? Nanosegundos, milisegundos o segundos?
6. **Fix con Prueba**: Proporciona el fix y prueba que elimina el race mostrando que el mismo entrelazamiento ahora produce resultados correctos.
7. **Test de Estres**: Genera un test que amplifica la ventana del race para hacer el bug reproducible de forma confiable.

Ejemplo de Salida

Estado compartido: `orderTotal` (escrito por addItem y applyDiscount concurrentemente)
Seccion critica: Lineas 23-25 — leer total, calcular nuevo total, escribir total (no es atomico)
Escenario race: Thread A lee total=100 → Thread B lee total=100 → A escribe 120 → B escribe 90 (sobreescribe la actualizacion de A)
Ventana de timing: ~2ms (round-trip de base de datos entre lectura y escritura)
Fix: Envolver en transaccion con SELECT FOR UPDATE, o usar incremento atomico
Test: Lanzar 50 requests concurrentes al mismo pedido — verificar que el total final coincida con la suma secuencial

Cuando Usar

Usa este skill cuando observes bugs intermitentes que desaparecen al agregar logging o ejecutar en modo debug, cuando los datos son ocasionalmente inconsistentes bajo acceso concurrente, o cuando tu aplicacion se bloquea bajo patrones de carga especificos.

Tips Pro

• Agregar un sleep lo hace reproducible — inserta await sleep(100) entre la lectura y escritura del estado compartido para ampliar artificialmente la ventana del race.
• El logging puede ESCONDER races — operaciones de I/O como console.log introducen puntos de sincronizacion que cambian el timing. Si agregar logs hace desaparecer el bug, definitivamente tienes una race condition.
• Revisa los niveles de aislamiento de la base de datos — la mayoria de race conditions en web apps son races de base de datos. READ COMMITTED permite lecturas fantasma.
• El patron TOCTOU — Time-Of-Check-To-Time-Of-Use: verificar una condicion y actuar sobre ella no es atomico. Siempre usa operaciones check-and-act atomicas.