Acción perdida / rollback: 36 causas y sus responsables

También se dice: la habilidad no salió, me devolvió el objeto, el intercambio falló

Abrir en la guía de síntomas interactiva →

Una acción que hiciste claramente se anula como si nunca hubiera pasado, o el resultado se revierte mucho después.

Usas la habilidad y no se activa. Un objeto que compraste desaparece, o al volver a conectarte todo está como hace unos minutos.

La solicitud se perdió (pérdida de paquetes, cola desbordada), el servidor resolvió algo distinto de lo que veías (diferencia en el momento de la validación, rechazo después del feedback anticipado) o falló el guardado (bloqueo o fallo de la BD, crash del servidor).

Causas de este síntoma

L1 Proceso del juego en el cliente

Error de sincronización del reloj: Si la hora del servidor que estima el cliente es errónea, el momento de interpolación y la validación de los cooldowns quedan desfasados. (Desarrollo de cliente (Equipo de desarrollo))

L5 Equipos de red del centro de datos

Límites de conexiones y puertos del gateway NAT en la nube: Cuando los servidores de una subred privada abren conexiones hacia fuera (autenticación de la plataforma, pagos, API externas), el gateway NAT cambia su dirección y su puerto antes de enviarlas. Si las conexiones simultáneas hacia un mismo destino superan el límite de puertos del gateway, las conexiones nuevas fallan. (Infraestructura de red (Equipo de infraestructura))
Microrráfagas en el switch: Cuando varios servidores envían paquetes a miles de jugadores en el mismo instante, el pequeño búfer del puerto del switch donde se junta ese tráfico se desborda en menos de 1 ms. (Desarrollo de servidor (Equipo de desarrollo))

L6 Tarjeta de red del servidor

Búfer circular (ring buffer) insuficiente: Si el búfer circular, donde la NIC guarda los paquetes un momento, es pequeño, se desborda cuando llegan muchos de golpe y los paquetes se descartan. (Infraestructura de servidores (Equipo de infraestructura))
Límite de PPS de la nube superado: Cada tipo de servidor en la nube tiene límites de paquetes por segundo y de ancho de banda, y lo que los supera se descarta en silencio. (Infraestructura de servidores (Equipo de infraestructura))

L7 SO del servidor (kernel)

OOM killer: Cuando Linux se queda sin memoria, elige el proceso que más memoria usa y lo mata a la fuerza. Casi siempre es el servidor del juego. (Desarrollo de servidor (Equipo de desarrollo))
Salto del reloj del sistema (step de NTP): Si el reloj del servidor se adelanta o se atrasa varios segundos de golpe, los temporizadores que dependen del reloj del sistema se disparan todos a la vez o se detienen. (Desarrollo de servidor (Equipo de desarrollo))
Agotamiento de puertos efímeros en conexiones entre servidores: Si el servidor del juego abre y cierra conexiones cortas con frecuencia hacia la BD u otros servidores, las conexiones cerradas siguen ocupando su puerto un tiempo y no se pueden abrir conexiones nuevas. (Desarrollo de servidor (Equipo de desarrollo))

L8 Sockets y protocolos

Configuración de retransmisión del UDP confiable: Si las reglas de retransmisión implementadas sobre UDP son demasiado conservadoras, la recuperación es lenta; si son demasiado agresivas, congestionan todavía más la conexión. (Desarrollo de servidor (Equipo de desarrollo))

L9 Proceso del juego en el servidor

Acumulación en la cola de mensajes: Si las solicitudes llegan más rápido de lo que se procesan y se acumulan en la cola, las últimas se procesan varios segundos después o se descartan. (Desarrollo de servidor (Equipo de desarrollo))
Crash del servidor: Si el proceso del servidor muere por un error no controlado, todos los jugadores de ese servidor se desconectan a la vez. (Desarrollo de servidor (Equipo de desarrollo))
Cambio del patrón de tráfico tras un parche: Si nuevo contenido, efectos o campos sincronizados aumentan el tamaño y la frecuencia de los paquetes, un servidor que iba bien empieza a chocar tras el parche con los límites de MTU, ancho de banda o número de paquetes. (Desarrollo de servidor (Equipo de desarrollo))

L11 Disco

Disco lleno: Si los logs y los volcados se acumulan hasta llenar el disco, las escrituras fallan y, si no hay nada previsto, el servidor se cae. (Infraestructura de servidores (Equipo de infraestructura))

L12 Base de datos

Contención de bloqueos en una fila caliente: Si todos intentan modificar la misma fila (el almacén del gremio, un objeto popular de la casa de subastas, un contador global del servidor), el bloqueo solo lo consigue uno cada vez. (Desarrollo de servidor (Equipo de desarrollo))
Deadlock en la BD: Si dos transacciones (operaciones de BD que se procesan como un solo bloque) esperan cada una la fila que bloqueó la otra, la BD cancela una de ellas a la fuerza. (Desarrollo de servidor (Equipo de desarrollo))
Retraso de replicación: Si se escribe en la BD principal y se lee de una réplica, cuando la réplica va con retraso no se ve lo que se acaba de escribir. (Infraestructura de BD (Equipo de infraestructura))
Procesos batch masivos: Calcular rankings, enviar correo del juego en masa o limpiar datos antiguos con el servicio en marcha acapara bloqueos y disco. (Desarrollo de servidor (Equipo de desarrollo))
Failover de la BD: Cuando la BD principal cae, no se puede escribir mientras se cambia a la de respaldo, y los últimos datos que no llegaron a replicarse pueden perderse. (Infraestructura de BD (Equipo de infraestructura))
Pérdida de progreso por intervalos de guardado largos: Si para reducir la carga solo se guarda una vez cada varios minutos, cuando el servidor se cae entre dos guardados se pierde el progreso. (Desarrollo de servidor (Equipo de desarrollo))
Transacciones abiertas durante mucho tiempo: Si una transacción permanece abierta mucho tiempo, sigue reteniendo sus bloqueos y la BD no puede limpiar (purge) las versiones antiguas de los datos, así que todo se vuelve cada vez más lento. (Desarrollo de servidor (Equipo de desarrollo))
Bloqueos por cambios de esquema (DDL) en producción: Si se añade una columna o un índice a una tabla con el servicio en marcha, un bloqueo que solo se necesita durante un instante puede dejar esperando a todas las solicitudes que usan esa tabla. (Infraestructura de BD (Equipo de infraestructura))

L13 Arquitectura y operación de servidores

Caída de un servidor auxiliar: Si falla un servidor que funciona aparte del servidor del juego, como el del chat, los grupos o la casa de subastas, solo deja de funcionar esa función. (Desarrollo de servidor (Equipo de desarrollo))
Desfase de reloj entre servidores: Si cada servidor tiene un reloj un poco distinto, las comprobaciones de cooldowns, buffs y comienzos de evento no coinciden entre servidores. (Infraestructura de servidores (Equipo de infraestructura))
Dependencia de servicios externos: Si un servicio externo, como el login de la plataforma, los pagos o la verificación de identidad, va lento o se detiene, todo se bloquea en ese paso. (Externo (Externo))
Errores de matchmaking y asignación de región: Si a un jugador se le asigna un servidor de una región lejana cuando hay una cercana, tiene siempre el ping alto aunque su conexión esté bien. (Desarrollo de servidor (Equipo de desarrollo))
Certificado TLS expirado o mal configurado: Si el certificado de un servidor de login, de API o de parches expira o le falta el certificado intermedio, desde ese momento falla la conexión TLS de los clientes que abren una conexión nueva. (Infraestructura de red (Equipo de infraestructura))

Diseño del netcode

Sin búfer de inputs para habilidades: Si no se puede presionar la siguiente habilidad hasta que el servidor confirme que terminó la anterior, cada combo arrastra un tiempo de ida y vuelta. (Desarrollo de cliente (Equipo de desarrollo))
Ventanas de tiempo cortas que el ping consume: Si el tiempo para reaccionar es corto, como en las esquivas, los parries o los bloqueos, el ping consume ese margen y aparecen ataques imposibles de evitar. (Desarrollo de servidor (Equipo de desarrollo))
Registro de impactos sin compensación de lag: Si el servidor resuelve los impactos solo con “la posición actual en el servidor”, lo que viste en tu pantalla y el resultado no coinciden. (Desarrollo de servidor (Equipo de desarrollo))
Compensación de lag excesiva: Si se rebobina demasiado a favor del atacante, a quien recibe el disparo le dan aunque ya se haya escondido. (Desarrollo de servidor (Equipo de desarrollo))
Autoridad del cliente: Si cada cliente decide sus propios resultados, en tu pantalla todo va fluido, pero los resultados no coinciden con los de otras pantallas y el juego queda expuesto a las trampas. (Desarrollo de servidor (Equipo de desarrollo))
Validación del servidor demasiado estricta: Si el servidor comprueba con demasiada rigidez la velocidad de movimiento, los cooldowns o el alcance, rechaza incluso inputs legítimos que llegaron juntos por el jitter. (Desarrollo de servidor (Equipo de desarrollo))
Rechazo del servidor tras el feedback anticipado: Si el servidor no acepta después un golpe o una habilidad que tu pantalla ya mostró, lo que viste claramente queda anulado. (Desarrollo de cliente (Equipo de desarrollo))
Tasa de envío de snapshots baja: Si el servidor envía las actualizaciones de posición (snapshots) solo unas pocas veces por segundo, hay que alargar en proporción el búfer de interpolación, y los demás personajes se ven más en el pasado. (Desarrollo de servidor (Equipo de desarrollo))

Problemas que solo afectan a algunos

Falsos positivos de validación concentrados en un ISP: Los inputs de quienes usan conexiones con mucho jitter llegan a ráfagas, así que caen a menudo en las comprobaciones de velocidad y cooldown del servidor. (Desarrollo de servidor (Equipo de desarrollo))
Un miembro del grupo con lag y las mecánicas del jefe: En las mecánicas de raid en las que todos deben reaccionar juntos en un momento preciso, la reacción tardía de una sola persona con lag hace fracasar a todo el grupo. (Desarrollo de servidor (Equipo de desarrollo))

Ver la guía de síntomas interactiva