Soluciona las condiciones de carrera: elimina errores asíncronos intermitentes en tu aplicación

Cómo se ven los errores asíncronos intermitentes en la vida real

Un error asíncrono intermitente ocurre cuando haces la misma acción dos veces y obtienes dos resultados distintos. Haces clic en el mismo botón, envías el mismo formulario o ejecutas la misma tarea, pero el resultado cambia. Una vez funciona. La siguiente falla, o funciona a medias y deja datos en un estado extraño.

El trabajo asíncrono aumenta la probabilidad porque las tareas no terminan en una línea ordenada. Peticiones, trabajos en cola, temporizadores y escrituras en la base de datos pueden solaparse. El orden puede cambiar por pequeñas diferencias de tiempo: retrasos en la red, una consulta lenta a la base de datos, un reintento o que un usuario haga la misma acción dos veces.

Por eso las condiciones de carrera a menudo parecen “aleatorias”. El error es real, pero solo aparece cuando dos cosas suceden en el orden desafortunado. Por ejemplo:

• Un usuario hace doble clic en “Pagar ahora” y dos peticiones crean dos pedidos.
• Un trabajo en segundo plano reintenta tras un timeout, pero el primer intento ya había tenido éxito.
• Dos pestañas actualizan el mismo perfil y la última respuesta sobrescribe datos más recientes.
• Un webhook llega antes de que se confirme el registro del que depende.

No necesitas ser un experto para diagnosticar estos casos. Si puedes responder “¿qué ocurrió primero?” ya estás pensando en la dirección correcta. El objetivo es dejar de adivinar y empezar a observar: qué acciones se ejecutaron, en qué orden y qué creía cada una sobre el estado en ese momento.

Dónde suelen esconderse las condiciones de carrera

Las condiciones de carrera rara vez están en la línea de código obvia que estás mirando. Se esconden en las grietas entre pasos: después de un clic, antes de que termine un reintento, mientras un trabajo en segundo plano aún se ejecuta. Si vas a arreglar condiciones de carrera, empieza por mapear todos los lugares donde el trabajo puede ocurrir dos veces o en un orden diferente al esperado.

Un lugar común son las colas y los trabajos en segundo plano. Un evento puede convertirse en dos trabajos (o el mismo trabajo se reintenta), y ambos funcionan bien por separado. Juntos crean duplicados, procesan fuera de orden o desencadenan una tormenta de reintentos que hace que el sistema parezca aleatorio.

Las peticiones web son otra fuente clásica. Los usuarios hacen doble clic, las redes móviles reintentan y los navegadores mantienen pestañas paralelas más tiempo del que crees. Dos peticiones golpean el mismo endpoint, cada una lee el mismo estado antiguo y luego ambas escriben, y la última escritura gana silenciosamente.

Las actualizaciones de estado son donde las cosas se vuelven sutiles. Puedes tener dos actualizaciones que sean válidas, pero que colisionen. Una actualización posterior puede sobrescribir un valor más nuevo porque empezó antes, o porque el código asume que es el único que escribe.

Estos son los lugares para revisar primero:

• Consumidores de colas y workers que pueden ejecutarse concurrentemente
• Jobs programados (cron) que pueden solaparse si una ejecución es lenta
• Lógica de “reintentar en fallo” que no es idempotente
• Llamadas a APIs de terceros que pueden tener éxito parcial antes de expirar
• Cualquier flujo que haga lectura-modificación-escritura sin una protección

Ejemplo: una app generada por IA envía un “email de bienvenida” desde una petición web y también desde un trabajo en segundo plano “por si acaso”. Bajo carga, ambas vías se disparan y ves duplicados solo a veces. El error no está en el código del email. Es la falta de una regla sobre quién puede enviar y cuántas veces.

Señales rápidas que apuntan a no determinismo

Los errores no deterministas parecen mala suerte: aparece un 500, actualizas y funciona. Ese patrón de “desaparece al reintentar” es una de las señales más claras de que tratas con timings, no con una única línea de código rota.

Observa qué pasa con los datos. Si un registro a veces falta, a veces se duplica o a veces es sobrescrito por un valor más antiguo, algo está actualizando lo mismo desde dos lugares. Suele manifestarse como “pago capturado dos veces”, “email enviado dos veces” o “perfil guardado pero campos revertidos”.

Los logs suelen delatarte, incluso cuando el bug no lo hace. Si ves la misma acción dos veces con el mismo usuario y payload (dos ejecuciones de un job, dos llamadas a la API, dos handlers de webhook), asume concurrencia o reintentos hasta que se demuestre lo contrario.

Señales rápidas a buscar

Estos patrones aparecen una y otra vez cuando necesitas arreglar condiciones de carrera:

• Reportes de bug que dicen “no puedo reproducirlo”, especialmente en distintos dispositivos o redes
• Errores que suben cuando el tráfico es mayor o la base de datos está más lenta
• Un flujo que falla solo cuando hay múltiples pestañas abiertas o usuarios hacen doble clic
• Una cola de jobs que “a veces” procesa fuera de orden o ejecuta duplicados después de reintentos
• Tickets de soporte que se agrupan alrededor de timeouts, reintentos o rendimiento degradado

Un ejemplo concreto: dos peticiones de checkout llegan cerca en el tiempo (doble clic + respuesta lenta). Ambas ven “inventario disponible”, ambas lo reservan y solo una falla después. El reintento “arregla” la situación, enmascarando el problema real.

Si heredaste un prototipo generado por IA, estos síntomas son comunes porque los flujos asíncronos suelen estar pegados sin una propiedad clara. FixMyMess audita rápidamente estos caminos trazando cada petición y ejecución de job de extremo a extremo antes de tocar el código.

Instrumenta primero: el logging mínimo que compensa

Cuando intentas arreglar condiciones de carrera añadiendo “esperas” o sleeps, normalmente haces que el bug sea más difícil de ver. Unos pocos logs bien escogidos te dirán qué está ocurriendo realmente, aunque la falla sea rara.

Empieza dando a cada acción de usuario o ejecución de job un ID de correlación. Úsalo en todas partes: la petición web, el job en cola y cualquier llamada descendente. Cuando alguien informe “falló una vez”, podrás seguir un hilo por todo el sistema en lugar de leer ruido no relacionado.

Registra el inicio y el fin de cada paso importante, con timestamps. Mantén el formato simple y consistente para comparar ejecuciones. También registra el recurso compartido que se toca, como el ID de fila de la BD, la clave de caché, la dirección de email o el nombre de archivo. La mayoría de errores asíncronos intermitentes ocurren cuando dos flujos tocan lo mismo en distinto orden.

Un conjunto mínimo de logs que suele compensar:

• correlation_id, user_id (o session_id) y request_id/job_id
• nombre del evento y nombre del paso (start, finish)
• timestamp y duración
• identificadores de recursos (ID de fila, clave de caché, nombre de archivo)
• retry_count y error_type (timeout vs validación vs conflicto)

Haz los logs seguros. Nunca imprimas secretos, tokens, contraseñas en claro o datos completos de tarjetas. Si necesitas confirmar “mismo valor”, registra una huella corta (por ejemplo, los últimos 4 caracteres o una versión enmascarada).

Ejemplo: un usuario hace doble clic en “Pagar”. Con IDs de correlación y logs de inicio/fin, puedes ver dos peticiones compitiendo por actualizar el mismo order_id, una reintentando tras un timeout. Aquí es donde los equipos suelen traer a FixMyMess: auditamos el codebase y añadimos la instrumentación adecuada antes de tocar la lógica, para que la causa real quede obvia.

Crea una reproducción fiable sin adivinar

Los errores asíncronos intermitentes parecen imposibles porque desaparecen cuando los miras. La forma más rápida de arreglar condiciones de carrera es dejar de “probar cosas” y construir un caso que falle de forma repetible.

Empieza por elegir un flujo que falle y escribe la secuencia esperada en palabras sencillas. Manténlo corto, por ejemplo: “Usuario hace clic en Pagar -> petición crea orden -> job reserva inventario -> la UI muestra éxito”. Esto se convierte en tu referencia de lo que debería pasar y de lo que ocurre realmente.

Ahora facilita la aparición del bug presionando el timing y la concurrencia. No esperes a que ocurra de forma natural.

• Fuerza acciones paralelas: doble clic, abre dos pestañas o ejecuta dos workers contra la misma cola.
• Añade deliberadamente un retardo en el paso sospechoso (antes de una escritura, después de una lectura, antes de una llamada externa).
• Ralentiza el entorno: limita la red, añade latencia en la BD o ejecuta la tarea en un bucle apretado.
• Reduce el alcance: reproduce en el handler o job más pequeño que puedas aislar.
• Escribe los inputs exactos y la configuración de timing para que cualquiera pueda repetirlo.

Un ejemplo concreto: el botón “Crear proyecto” a veces genera dos proyectos. Pon un retraso de 300 ms justo antes del insert, luego haz doble clic rápido o envía desde dos pestañas. Si puedes desencadenar duplicados 8 de cada 10 veces, tienes algo sobre lo que trabajar.

Mantén un script corto de reproducción (incluso unos pasos manuales) y trátalo como una prueba: ejecútalo antes y después de cada cambio. Si heredas una app generada por IA, equipos como FixMyMess suelen empezar construyendo este repro primero, porque convierte una queja vaga en una falla medible.

Paso a paso: estabiliza el flujo en vez de perseguir el timing

Si intentas arreglar condiciones de carrera añadiendo “un retardo” o “esperando a que termine”, el bug suele moverse a otro sitio. El objetivo es hacer que el flujo sea seguro aunque las cosas ocurran dos veces, fuera de orden o al mismo tiempo.

Empieza por nombrar la cosa compartida que puede corromperse. Suele ser una fila (registro de usuario), un contador (saldo) o un recurso limitado (inventario). Si dos caminos pueden tocarlo a la vez, ese es el problema real, no el timing.

Una forma práctica de arreglar condiciones de carrera es elegir una estrategia de seguridad y aplicarla de forma consistente:

1. Mapea quién lee y quién escribe el recurso compartido (petición A, job B, webhook C).
2. Decide la regla: serializar el trabajo (uno a la vez), bloquear el recurso o hacer que la operación sea segura para repetir.
3. Añade una clave de idempotencia para cualquier acción que pueda reintentarse (doble clic del usuario, reintento de red, reentrega de cola).
4. Protege las escrituras con una transacción o una actualización condicional para no perder el cambio de otro.
5. Compruébalo con tests de concurrencia y ejecuciones repetidas, no con un “funciona en mi máquina”.

Ejemplo: dos peticiones “Realizar pedido” llegan al mismo tiempo. Sin protección, ambas leen inventory=1, ambas restan y envías dos ítems. Con idempotencia, la segunda petición reutiliza el resultado de la primera. Con una actualización condicional (solo restar si inventory sigue siendo 1) dentro de una transacción, solo una petición puede tener éxito.

Si heredaste código generado por IA, estas salvaguardas suelen faltar o ser inconsistentes. FixMyMess normalmente empieza añadiendo la idempotencia mínima y reglas de escritura segura, y luego reejecuta el mismo escenario docenas de veces hasta que se vuelve aburridamente estable.

Colas y trabajos en segundo plano: duplicados, reintentos, orden

La mayoría de las colas entregan jobs al menos una vez. Eso significa que el mismo job puede ejecutarse dos veces, o ejecutarse después de un job más nuevo, incluso si solo hiciste clic una vez. Si tu handler asume que es la única ejecución, obtendrás resultados raros: cargos duplicados, emails dobles o un registro que cambia entre dos estados.

El enfoque más seguro es hacer que cada job sea seguro para repetirse. Piensa en resultados, no en intentos. Un job debe poder ejecutarse de nuevo y aun así llegar al mismo estado final.

Un patrón práctico que ayuda a arreglar condiciones de carrera en procesamiento en segundo plano:

• Añade una clave de idempotencia (orderId, userId + action + date) y guarda “ya procesado” antes de hacer efectos secundarios.
• Registra un estado claro del job (pending, running, done, failed) para que reejecuciones puedan salir temprano.
• Trata las llamadas externas (pago, email, subida de archivo) como pasos “hacer una vez” con sus propias comprobaciones de deduplicación.
• Protégete contra eventos fuera de orden usando un número de versión o timestamp y descartando actualizaciones antiguas.
• Separa fallos reintentables (timeouts, límites de tasa) de los no reintentables (entrada inválida) y deja de reintentar cuando nunca va a funcionar.

Los problemas de orden son fáciles de pasar por alto. Ejemplo: un job “cancelar suscripción” se ejecuta y luego llega un job de “renovar suscripción” retrasado que re-activa al usuario. Si guardas una versión monótonamente creciente (o updatedAt) con cada cambio de suscripción, el handler puede rechazar mensajes obsoletos y mantener la verdad más reciente.

Ten cuidado con los locks globales. Pueden ocultar el bug ralentizando todo y luego perjudicarte en producción bloqueando trabajo no relacionado. Prefiere bloqueos por entidad (un usuario o un pedido a la vez) o comprobaciones de idempotencia.

Si heredaste un worker generado por IA que duplica trabajo al azar, equipos como FixMyMess suelen empezar añadiendo idempotencia y checks de “evento obsoleto” primero. Esos dos cambios suelen convertir un comportamiento intermitente en resultados predecibles rápidamente.

Peticiones web: doble clic, reintentos y sesiones paralelas

La mayoría de los errores de petición ocurren cuando la misma acción se envía dos veces, o cuando dos acciones llegan en el orden “equivocado”. Los usuarios hacen doble clic, los navegadores reintentan en redes lentas, las apps móviles reenvían tras un timeout y múltiples pestañas actúan como personas distintas.

Para arreglar condiciones de carrera aquí, asume que el cliente puede y enviará duplicados. El servidor debe ser correcto aunque la UI esté mal, lenta o desconectada por un momento.

Haz que los endpoints “hacer la acción” sean seguros para repetir

Si una petición puede crear efectos secundarios (cobrar una tarjeta, crear un pedido, enviar un email), hazla idempotente. Un enfoque simple es una clave de idempotencia por acción. Guárdala con el resultado y, si vuelve a aparecer la misma clave, devuelve el mismo resultado.

También vigila los timeouts. Un fallo común es: el servidor aún está procesando, el cliente hace timeout y reintenta. Sin deduplicación, obtienes dos pedidos, dos emails de restablecimiento o dos mensajes de bienvenida.

Aquí tienes un conjunto rápido de protecciones que suelen compensar:

• Requerir una clave de idempotencia para endpoints de creación/envío y deduplicar por (usuario, clave)
• Usar respuestas de error consistentes para que los clientes reintenten solo en errores seguros
• Loggear request ID y la clave de idempotencia en cada intento
• Poner los efectos secundarios después de haber persistido el registro de “esta acción ocurrió”
• Tratar “ya hecho” como éxito, no como un error alarmante

Evita que peticiones paralelas sobrescriban el estado

Los sobrescritos ocurren cuando dos peticiones leen el mismo estado antiguo y luego ambas escriben actualizaciones. Ejemplo: dos pestañas actualizan un perfil y la última gana, borrando silenciosamente lo de la otra.

Prefiere comprobaciones en el servidor como números de versión (bloqueo optimista) o reglas explícitas como “solo actualizar si el estado sigue siendo PENDING”. Si heredaste handlers generados por IA que hacen lectura-modificación-escritura sin protecciones, este es un lugar común donde FixMyMess encuentra informes de usuarios que “a veces guarda, a veces no”.

Actualizaciones de estado: prevenir sobrescrituras y datos inconsistentes

Mucho del comportamiento intermitente no es “asíncrono” en una cola o red. Son dos partes de la app actualizando la misma pieza de estado en un orden distinto cada ejecución. Hoy gana una petición, mañana la otra.

El problema clásico es la pérdida de actualización: dos workers leen el mismo valor antiguo, ambos calculan un nuevo valor y la última escritura sobrescribe a la primera. Ejemplo: dos dispositivos actualizan la configuración de notificaciones de un usuario. Ambos leen “habilitado”, uno lo apaga, el otro cambia el sonido, y el registro final pierde silenciosamente un cambio.

Cuando puedas, prefiere operaciones atómicas en vez de leer y luego escribir. Las bases de datos suelen soportar primitivas seguras como incremento atómico, compare-and-set y “update where version = X”. Eso convierte el timing en una regla clara: solo una actualización puede tener éxito y el perdedor reintenta con datos frescos.

Una segunda solución es validar transiciones de estado. Si un pedido solo puede pasar de pending -> paid -> shipped, rechaza shipped -> paid aunque llegue tarde. Esto evita que peticiones tardías, reintentos o jobs en segundo plano hagan retroceder el estado.

La caché puede empeorar esto. Una lectura obsoleta desde caché puede desencadenar una escritura “correcta” basada en datos antiguos. Si cachéas estado que impulsa escrituras, asegúrate de invalidar la caché en actualizaciones o de leer la fuente de verdad justo antes de escribir.

Una forma simple de arreglar condiciones de carrera es la propiedad: decidir un único lugar que pueda actualizar una pieza de estado y encaminar todos los cambios a través de él. Buenas reglas de propiedad suelen verse así:

• Un servicio es el dueño de la escritura, otros solo solicitan cambios
• Una tabla o documento es la fuente de la verdad
• Las actualizaciones incluyen un número de versión (o timestamp) y se rechazan si están obsoletas
• Solo se aceptan transiciones de estado permitidas

En FixMyMess, a menudo vemos apps generadas por IA que actualizan el mismo registro desde código UI, handlers API y jobs en segundo plano al mismo tiempo. Hacer explícita la propiedad suele ser la forma más rápida de detener datos inconsistentes.

Trampas comunes que mantienen vivos los bugs intermitentes

La forma más rápida de perder una semana es “tratar el reloj” en vez de la causa. Si el bug depende del timing, puedes hacerlo desaparecer por un día y aún así desplegarlo.

Un error común es añadir más reintentos cuando no tienes idempotencia. Si un job de pago falla a medias y luego reintenta, puedes cobrar dos veces. Los reintentos solo son seguros cuando cada intento puede ejecutarse de nuevo sin cambiar el resultado.

Otra trampa es esparcir delays aleatorios para “separar colisiones”. A menudo oculta el problema en staging y luego empeora la producción porque los patrones de carga cambian. Los delays también hacen tu sistema más lento y más difícil de razonar.

Los locks grandes pueden volverse en contra. Un mutex gigante alrededor “de todo el flujo” puede detener la flakiness, pero crear un nuevo modo de fallo: esperas largas, timeouts y reintentos en cascada que devuelven el bug en otra forma.

Vigila estos patrones que mantienen el comportamiento no determinista:

• Tratar todo fallo como reintentable (timeouts, errores de validación, errores de auth y conflictos requieren manejo distinto)
• Declarar victoria porque pasó localmente una vez (la verdadera concurrencia rara vez aparece en un portátil tranquilo)
• Loggear solo “ocurrió un error” sin request/job id, número de intento o versión de estado
• Arreglar síntomas en una capa mientras la carrera sigue existiendo debajo (UI, API y worker pueden solaparse)
• “Hacks temporales” que se vuelven permanentes (reintentos extra, sleeps o bloques catch-all)

Si heredaste un codebase generado por IA con estas curitas, una auditoría enfocada puede mostrar rápidamente dónde reintentos, locks y falta de idempotencia están enmascarando la verdadera carrera. Ahí es donde una reparación dirigida vence a más conjeturas.

Checklist rápido antes de desplegar la corrección

Antes de darlo por hecho, asegúrate de que no estás simplemente “ganando la lotería del timing”. El objetivo es arreglar condiciones de carrera para que las mismas entradas produzcan siempre el mismo resultado.

Aquí tienes una checklist previa al despliegue que detecta la mayoría de los culpables recurrentes:

• Ejecuta dos veces a propósito. Dispara la misma acción dos veces (doble clic, dos workers, dos pestañas) y confirma que el resultado sigue siendo correcto, no solo “no roto”.
• Busca la cosa compartida. Identifica el recurso compartido (fila, archivo, clave de caché, saldo, bandeja) y decide cómo se protege: transacción, lock, índice único o actualización condicional.
• Audita reintentos por efectos secundarios. Si ocurre un reintento, ¿envías otro email, cobras de nuevo o escribes una fila duplicada? Si la respuesta es sí, añade idempotencia para que “misma petición” signifique “mismo efecto”.
• Compara orden en los logs. En una ejecución buena vs una mala, ¿llegan los eventos en distinto orden (job empezado antes de que exista el registro, callback antes de que se guarde el estado)? Las diferencias de orden indican que arreglaste síntomas, no la causa.
• Prefiere garantías atómicas a sleeps. Si una transacción, un índice único o “actualizar solo si la versión coincide” elimina el bug, eso suele ser más seguro que añadir retrasos.

Ejemplo: si “Crear suscripción” a veces cobra dos veces, verifica que la llamada al proveedor de pagos esté claveada por un token de idempotencia y que tu escritura en la BD esté protegida por una restricción única sobre ese token. Así los duplicados se convierten en no-ops inofensivos en lugar de incendios de soporte al cliente.

Ejemplo: estabilizar un flujo intermitente de extremo a extremo

Imagina un flujo simple: dos compañeros editan el mismo registro de cliente y un job en segundo plano también actualiza ese registro tras una importación. En demos todo parece bien, pero con usuarios reales empiezas a ver resultados extraños.

Hoy, la app usa “last write wins”. El Usuario A guarda, luego el Usuario B guarda un segundo después y sobrescribe los cambios de A sin avisar. Mientras tanto, el job en cola reintenta tras un timeout y envía la notificación “Cliente actualizado” dos veces.

Para confirmar que es no determinista (y arreglar las condiciones de carrera en vez de adivinar), puedes crear un repro repetible:

• Abre el registro en dos pestañas (Pestaña A y Pestaña B)
• Cambia campos distintos en cada pestaña
• Clica guardar en ambas pestañas en menos de un segundo
• Dispara el job en segundo plano y fuerza un reintento (por ejemplo lanzando temporalmente un error después de enviar)
• Revisa el estado final del registro y cuenta las notificaciones

Si cada ejecución termina distinto, has encontrado el bug de timing.

Estabilizarlo suele requerir dos cambios. Primero, haz las notificaciones idempotentes: añade una clave de idempotencia como customerId + eventType + version y guárdala, de modo que la misma notificación no pueda enviarse dos veces aunque un job reintente.

Segundo, haz la actualización del registro atómica. Envuelve la actualización en una transacción y añade una comprobación de versión (bloqueo optimista). Si la Pestaña B intenta guardar una versión antigua, devuelve un mensaje claro: “Este registro cambió, actualiza y vuelve a intentarlo” en lugar de sobrescribir en silencio.

Vuelve a probar el mismo repro 50 veces. Quieres resultados idénticos en cada ejecución: un estado final que puedas explicar y exactamente una notificación.

Este es el tipo de problema que FixMyMess suele ver en apps generadas por IA: existen reintentos y código asíncrono, pero faltan las barandillas (idempotencia, locks, transacciones). Hacer esas correcciones suele estabilizar el sistema rápido.

Próximos pasos: vuelve a hacer el sistema predecible

Elige los flujos donde la inestabilidad te hace más daño. No empieces por “toda la app”. Empieza por 2-3 flujos críticos donde un mal resultado sea costoso, por ejemplo: cobrar una tarjeta, crear una cuenta, hacer un pedido, enviar un email o actualizar inventario.

Escribe esos flujos en pasos sencillos (qué lo desencadena, qué llama, qué datos cambian). Ese pequeño mapa te da una “verdad” compartida cuando haya discusiones sobre timing. También facilita arreglar condiciones de carrera sin adivinar.

Elige una barrera que puedas desplegar esta semana. Cambios pequeños a menudo eliminan la mayor parte del riesgo:

• Añadir una clave de idempotencia a la acción que crea algo (pagos, pedidos, emails)
• Usar una actualización condicional (solo actualizar si la versión coincide o si el estado sigue siendo el esperado)
• Añadir una restricción única para que los duplicados fallen rápido y de forma segura
• Hacer ordering para un tópico de cola (o colapsar múltiples jobs en uno “estado más reciente”)
• Poner timeout y límite de reintentos donde hoy los reintentos corren indefinidamente

Si tu codebase fue generado por herramientas de IA y resulta difícil de entender, planifica una limpieza enfocada: un flujo, un responsable y una semana para eliminar estado compartido oculto y reintentos “mágicos”.

Ejemplo: si “Crear orden” a veces envía dos emails de confirmación, haz primero el envío de email idempotente y luego ajusta el worker de la cola para que pueda reintentar sin cambiar el resultado.

Si quieres un plan rápido y claro, FixMyMess puede hacer una auditoría de código gratuita para localizar condiciones de carrera, reintentos y escrituras inseguras. Y si necesitas estabilizar rápido, podemos diagnosticar y reparar prototipos generados por IA y dejarlos listos para producción en 48-72 horas con verificación experta.