Ação perdida / rollback: 36 causas e quem resolve

Também chamado de: skill não saiu, item voltou, troca falhou

Abrir no catálogo de sintomas ilustrado →

Uma ação que você com certeza fez é desfeita, ou o resultado é revertido bem depois.

Você aperta a skill e ela não sai. O item comprado some, ou ao reconectar tudo volta ao estado de minutos atrás.

O pedido se perdeu (perda de pacotes, estouro de fila), o servidor decidiu diferente do que sua tela mostrou (diferença no momento da decisão, rejeição depois do feedback no cliente) ou o salvamento falhou no meio (lock ou falha no banco de dados, crash do servidor).

Causas deste sintoma

L1 Processo do jogo no cliente

Erro na sincronização do relógio: Se a hora do servidor estimada pelo cliente estiver errada, o momento da interpolação e a decisão sobre o cooldown ficam desalinhados com o servidor. (Desenvolvimento do cliente (Equipe de desenvolvimento))

L5 Equipamentos de rede do data center

Limite de conexões e portas do gateway NAT na nuvem: As conexões que servidores em uma sub-rede privada abrem para fora (autenticação da plataforma, pagamentos, APIs externas) passam pelo gateway NAT, que troca o endereço e a porta. Se as conexões simultâneas para o mesmo destino passam do limite de portas do gateway, as novas conexões falham. (Infraestrutura de rede (Equipe de infraestrutura))
Microburst no switch: Quando vários servidores mandam pacotes para milhares de jogadores no mesmo instante, o buffer pequeno da porta do switch onde esse tráfego converge transborda em menos de 1 ms. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L6 Placa de rede do servidor

Ring buffer insuficiente: Se o ring buffer, onde a NIC guarda os pacotes por um instante, é pequeno, um pico repentino faz o buffer transbordar e os pacotes são descartados. (Infraestrutura de servidores (Equipe de infraestrutura))
Limite de PPS da nuvem excedido: Cada tipo de instância na nuvem tem limites de pacotes por segundo e de largura de banda, e o excedente é descartado em silêncio. (Infraestrutura de servidores (Equipe de infraestrutura))

L7 SO do servidor (kernel)

OOM killer: Quando a memória acaba, o Linux escolhe o processo que mais usa memória e o mata à força. Em geral, é o servidor do jogo. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Salto do relógio do sistema (step do NTP): Quando o relógio do servidor é ajustado alguns segundos para frente ou para trás de uma vez, os timers que dependem do relógio do sistema disparam todos juntos ou ficam parados. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Esgotamento de portas efêmeras em conexões entre servidores: Quando o servidor do jogo abre e fecha conexões curtas com frequência para o BD ou outros servidores, as conexões encerradas seguram a porta por um tempo e não dá para abrir conexões novas. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L8 Sockets e protocolos

Configuração de retransmissão do UDP confiável: Se as regras de retransmissão implementadas sobre o UDP forem conservadoras demais, a recuperação demora. Se forem agressivas demais, congestionam ainda mais a conexão. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L9 Processo do jogo no servidor

Acúmulo na fila de mensagens: Quando os pedidos chegam mais rápido do que são processados e se acumulam na fila, os últimos da fila só são processados segundos depois ou são descartados. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Crash do servidor: Quando um erro não tratado derruba o processo do servidor, todos que estavam naquele servidor são desconectados ao mesmo tempo. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Mudança no padrão de tráfego após um patch: Quando novos conteúdos, efeitos e campos sincronizados aumentam o tamanho e a frequência dos pacotes, um servidor que ia bem passa a bater nos limites de MTU, largura de banda e número de pacotes depois do patch. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L11 Disco

Disco cheio: Quando logs e dumps se acumulam e o disco enche, as escritas falham e, se o código não estiver preparado para isso, o servidor cai. (Infraestrutura de servidores (Equipe de infraestrutura))

L12 Banco de dados

Contenção de lock em hot row: Quando todos tentam alterar a mesma linha (baú da guilda, item popular na casa de leilões, contador global do servidor), só um de cada vez consegue o lock. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Deadlock no banco de dados: Quando duas transações (operações do BD processadas como um bloco único) esperam, cada uma, pela linha em que a outra pôs lock, o BD cancela uma delas à força. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Atraso de replicação: Com as escritas no BD primário e as leituras em uma réplica, se a réplica fica para trás, o que acabou de ser gravado não aparece. (Infraestrutura de banco de dados (Equipe de infraestrutura))
Jobs em lote pesados: Rodar com o jogo no ar o cálculo de rankings, o envio de correio em massa ou a limpeza de dados antigos ocupa locks e disco. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Failover do banco de dados: Quando o BD primário cai, não dá para gravar durante a troca para o BD reserva, e os últimos dados que não foram replicados podem se perder. (Infraestrutura de banco de dados (Equipe de infraestrutura))
Perda de progresso por intervalo de salvamento longo: Se, para reduzir a carga, o salvamento só acontece a cada alguns minutos, uma queda do servidor nesse intervalo apaga o progresso. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Transação aberta por muito tempo: Uma transação aberta por muito tempo continua segurando locks, e o BD não consegue limpar as versões antigas dos dados (purge), então tudo vai ficando mais lento. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Lock de alteração de schema (DDL) em produção: Adicionar uma coluna ou um índice a uma tabela com o jogo no ar exige um lock por um instante, e só esse lock pode deixar esperando todas as requisições que usam a tabela. (Infraestrutura de banco de dados (Equipe de infraestrutura))

L13 Arquitetura e operação de servidores

Falha em servidor auxiliar: Quando falha um servidor que roda separado do servidor do jogo, como chat, party ou casa de leilões, só aquela função para de funcionar. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Diferença de relógio entre servidores: Quando cada servidor tem o relógio um pouco diferente, as decisões sobre cooldown, buffs e início de eventos divergem de um servidor para outro. (Infraestrutura de servidores (Equipe de infraestrutura))
Dependência de serviços externos: Quando um serviço externo, como login da plataforma, pagamento ou verificação de identidade, fica lento ou para, o jogador fica preso nessa etapa. (Externo (Externo))
Erro de matchmaking ou de atribuição de região: Quando o jogador é mandado para um servidor de uma região distante, mesmo havendo uma região próxima, só o ping dele fica sempre alto, ainda que a conexão esteja boa. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Certificado TLS expirado ou mal configurado: Quando o certificado do servidor de login, de API ou de patch expira, ou falta o certificado intermediário, a conexão TLS dos clientes que se conectam a partir desse momento falha. (Infraestrutura de rede (Equipe de infraestrutura))

Design de sincronização

Sem buffer de comandos para skills: Se a próxima skill só pode ser usada depois que o servidor confirma o fim da anterior, cada combo ganha um tempo de ida e volta no meio. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Janela de tempo curta consumida pelo ping: Quando o tempo para reagir é curto, como em esquiva, parry ou defesa, o ping consome esse tempo e surgem ataques impossíveis de evitar. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Registro de acerto sem compensação de lag: Se o servidor decide o acerto só pela “posição atual no servidor”, a decisão diverge do que você viu na tela. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Compensação de lag excessiva: Se o servidor volta no tempo demais a favor do atacante, quem leva o tiro é atingido mesmo já tendo se escondido. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Autoridade do cliente: Quando cada um decide o próprio resultado, sua tela fica fluida, mas os resultados divergem da tela dos outros e o jogo fica vulnerável a hacks. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Validação rígida demais no servidor: Se o servidor checa com rigidez demais a velocidade de movimento, o cooldown e o alcance, rejeita até inputs normais que chegaram juntos por causa do jitter. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Servidor rejeita o que o feedback no cliente já mostrou: Se o servidor não reconhece depois um golpe ou uma skill que sua tela já mostrou, o resultado que você viu claramente deixa de ter acontecido. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Taxa de envio de snapshots baixa: Se o servidor manda as atualizações de posição (snapshots) só algumas vezes por segundo, o buffer de interpolação precisa ser mais longo na mesma medida, e você vê os outros personagens mais no passado. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Problemas que só afetam alguns

Falsos positivos da validação concentrados em uma operadora: Quem usa conexão com jitter alto tem os inputs chegando agrupados e cai com frequência nas checagens de velocidade e cooldown do servidor. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Um membro da party com lag e a mecânica do boss: Em mecânicas de raid em que todos precisam reagir juntos em um momento definido, a reação atrasada de um jogador com lag vira falha da party inteira. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Ver o catálogo de sintomas ilustrado