Por que uma doação gera dois alertas após atualizar a fonte de navegador

Por que uma doação gera dois alertas

Após atualizar a fonte de navegador, a página é iniciada novamente. O script se reconecta ao servidor, inscreve-se nos eventos e cria manipuladores para exibir as notificações. Se o manipulador antigo não for removido ou se duas conexões estiverem ativas ao mesmo tempo, um único evento de doação será processado várias vezes.

A própria atualização não é necessariamente a causa da falha. Muitas vezes, ela apenas revela um erro na lógica de conexão. Por exemplo, a função de inicialização pode ser executada ao carregar a página, depois ao restabelecer a conexão e mais uma vez após receber uma mensagem de serviço. Cada execução adiciona uma nova inscrição no evento donation.

Como resultado, o servidor envia um único objeto de doação, mas o navegador chama a mesma função duas vezes. Às vezes, a duplicação ocorre no lado do servidor: a aplicação considera a nova conexão um destinatário separado e envia o evento tanto para a sessão antiga quanto para a nova. Por isso, primeiro é preciso identificar onde surge a repetição: na fonte, no manipulador ou na etapa de exibição.

Como localizar o ponto onde surge a duplicação

Comece com um teste simples. Abra o link da fonte de navegador em uma janela ou aba separada, deixe apenas uma instância da página e envie um evento de teste. Se o alerta aparecer uma vez, a causa provavelmente está relacionada às configurações da cena ou a várias instâncias da fonte. Se ele já se duplicar na aba separada, verifique o código da página e o mecanismo de inscrição.

É útil dividir o processamento da doação em várias etapas: recebimento do evento, validação do evento, enfileiramento do alerta e renderização. No log ou console, exiba temporariamente uma marcação em cada etapa. Se o registro de recebimento aparecer duas vezes, o problema está antes da camada visual. Se o evento for recebido uma vez, mas houver dois elementos na fila, o erro está no manipulador. Se a fila tiver um elemento e a tela mostrar dois alertas, verifique a função de exibição e o contêiner HTML.

Para diagnóstico, adicione a cada evento o seu identificador, caso ele seja transmitido nos dados da doação. Registre esse identificador no recebimento e antes da exibição. O mesmo identificador em duas chamadas indica que um único evento foi processado novamente. Dois identificadores diferentes indicam duas entregas, que precisam ser analisadas separadamente.

Verifique não apenas a quantidade de abas. No OBS, duas instâncias podem aparecer após copiar a cena, adicionar uma cena aninhada ou adicionar novamente a fonte de navegador com o mesmo endereço. Às vezes, uma fonte permanece em uma camada separada e a segunda é adicionada por cima dela. Visualmente, isso parece um alerta duplo, embora o evento tenha chegado uma única vez.

Reinscrição após reconexão

A causa mais comum é o manipulador ser adicionado a cada conexão, mas não ser removido ao desconectar. De forma simplificada, o problema é assim: a função executa socket.on com o manipulador de exibição do alerta, depois a conexão cai, a aplicação se conecta novamente e repete o socket.on. Depois disso, uma doação recebida chama duas funções. Na próxima reconexão, pode haver ainda mais.

O mesmo erro ocorre com addEventListener comum. Se a função de inicialização for chamada várias vezes, o navegador adiciona vários ouvintes para o mesmo evento. A verificação por uma flag de “inicialização já executada” nem sempre ajuda: em uma atualização completa da página, as variáveis são redefinidas, e na reconexão dentro da mesma página o problema continua.

A inscrição deve ser criada uma única vez por ciclo de vida da conexão, e a inscrição antiga deve ser explicitamente removida antes da nova. Para manipuladores de eventos, usa-se removeEventListener com a mesma referência de função passada na inscrição. Para bibliotecas com sockets, geralmente é necessário um método off, unsubscribe ou forma equivalente de cancelamento.

Um esquema mínimo para o socket pode ser assim: const onDonation = data => showAlert(data); socket.off('donation', onDonation); socket.on('donation', onDonation); function cleanup() { socket.off('donation', onDonation); window.removeEventListener('beforeunload', cleanup); socket.close(); } window.addEventListener('beforeunload', cleanup);

O importante aqui não é a biblioteca específica, mas a ordem das ações. O manipulador fica armazenado em uma variável, então pode ser removido com a mesma referência. Antes da nova inscrição, a antiga é removida, e ao fechar a página ou parar a fonte, o cleanup é executado. Se um novo socket for criado a cada execução, primeiro é preciso fechar o antigo e só depois criar o novo. Caso contrário, as duas conexões podem continuar recebendo os mesmos dados.

Na reconexão, também feche a conexão antiga e limpe os timers associados. Caso contrário, o socket antigo pode continuar recebendo dados enquanto o novo já está ativo. Isso acontece especialmente quando o código inicia um novo timer de reconexão sem cancelar o anterior.

O que verificar no OBS e na fonte de navegador

Se a janela separada mostrar o alerta uma vez, passe para a cena. Pare a pré-visualização, remova temporariamente as camadas extras e deixe apenas uma fonte de navegador. Depois, verifique o comportamento na cena desejada. Esse teste é mais rápido do que verificar todas as cenas e filtros ao mesmo tempo.

• Procure duas fontes com o mesmo endereço de página.
• Verifique cópias de cenas e cenas aninhadas onde o mesmo overlay possa estar presente.
• Confirme que o alerta não é exibido ao mesmo tempo pela fonte de navegador e por outra camada com a mesma página.
• Após alterar as configurações, reinicie completamente a fonte, e não apenas troque de cena.

Às vezes, o OBS mantém uma aba antiga da fonte de navegador após atualizar a URL ou os parâmetros. Fechar e adicionar novamente a fonte ajuda a testar a hipótese, mas não substitui a correção do código. Se o problema voltar após cada atualização, procure registro repetido do manipulador ou conexão dupla.

Considere também o atraso de desconexão. Ao atualizar, a sessão antiga pode não fechar instantaneamente. Se o servidor a considerar ativa por alguns segundos, um evento que chegue nesse intervalo pode ser entregue às duas sessões. A lógica normal do servidor deve remover conexões inativas e não deixar a inscrição após o fechamento da página.

Proteção contra reentrega de um mesmo evento

Mesmo com a fonte de navegador funcionando corretamente, um evento às vezes pode ser entregue novamente. Isso é possível em restabelecimento de conexão, reenvio de mensagem ou falha entre o recebimento do evento e a confirmação do seu processamento. Por isso, o manipulador do alerta deve ser resistente a repetições.

A melhor forma é verificar o identificador único da doação. Antes de enfileirar o evento, salve o identificador em um conjunto de eventos já processados. Se esse identificador já tiver aparecido, a repetição deve ser ignorada. A lista deve ser mantida por tempo limitado, para não crescer indefinidamente.

Não use apenas o valor, o nome do remetente ou o texto da mensagem para isso. Duas doações diferentes podem ter os mesmos dados. A verificação por horário também não é confiável: várias doações diferentes podem chegar quase simultaneamente. Se não houver identificador, pode-se comparar temporariamente uma combinação de campos e horário, mas isso é uma alternativa de reserva com risco de unir erroneamente dois eventos.

A proteção contra duplicatas deve ficar antes da exibição do alerta, e não dentro da animação. Caso contrário, a segunda chamada ainda adicionará um elemento à página, reproduzirá o som ou colocará mais um item na fila. Controle a fila separadamente: um evento deve ser adicionado a ela uma única vez, e a chamada repetida não deve iniciar uma segunda fila independente.

Se o evento for transmitido entre várias abas ou componentes, verifique se ele não está sendo processado por vários destinatários ao mesmo tempo. Um canal de mensagens compartilhado pode estar conectado a vários manipuladores. Nesse caso, é preciso manter apenas um consumidor ou definir explicitamente qual componente é responsável por exibir o alerta.

Por que limpar o cache nem sempre ajuda

Após atualizar a fonte de navegador, costuma-se recomendar a limpeza do cache. Isso pode corrigir a situação se uma versão antiga do script tiver sido carregada, mas o cache não remove manipuladores extras na página já em execução nem fecha a segunda cópia da fonte. Se a duplicação se repetir de forma estável após cada reconexão, a causa quase certamente está na lógica de conexão ou na estrutura da cena.

Verifique se a nova versão dos arquivos está realmente sendo carregada. Altere temporariamente o endereço do recurso ou use o mecanismo de atualização previsto e depois reinicie a fonte de navegador. Em seguida, faça novamente o teste com uma janela e uma instância da fonte. Não adicione parâmetros aleatórios ao link permanentemente: isso pode criar muitos variantes de cache e dificultar o diagnóstico.

Se houver um cache intermediário ou service worker, ele também pode entregar um script desatualizado. Nesse caso, compare a versão do arquivo carregado com a versão que você espera ver. Mas, mesmo com um arquivo antigo, é preciso eliminar a causa da reinscrição; caso contrário, o problema voltará após a próxima atualização.

O que verificar no código do alerta

Primeiro, localize todos os pontos em que socket.on, addEventListener, funções de conexão e início da fila são chamados. Às vezes, o problema não está em um único manipulador, mas no fato de dois módulos diferentes escutarem o evento donation de forma independente e cada um iniciar sua própria exibição.

Depois, verifique o ciclo de vida do componente, se o alerta for exibido por meio de um framework. A inscrição é colocada em um efeito ou bloco equivalente, que retorna uma função de limpeza. Não se deve criar um novo manipulador a cada atualização de estado sem remover o anterior. Em JavaScript comum, é importante armazenar a referência do socket ativo e do manipulador atual, para que possam ser fechados corretamente ao parar a página.

Verifique os timers de reconexão. Um novo timer não deve ser iniciado sobre o antigo. Caso contrário, após várias quedas, são criadas tentativas de conexão paralelas e, com elas, inscrições adicionais. Cada timer precisa de limpeza via clearTimeout ou clearInterval quando não for mais necessário.

Observe separadamente o código que exibe o alerta. Ele não deve adicionar o elemento à fila e, ao mesmo tempo, chamar imediatamente a função de exibição para o mesmo objeto. Verifique também se a animação não é iniciada novamente quando o estado do elemento muda. Se o log mostrar um recebimento e um item na fila, mas a tela exibir duas notificações, é exatamente aqui que se deve procurar.

Checklist de diagnóstico: o que fazer em ordem

1. Abra a URL da fonte de navegador em uma aba separada e envie uma doação de teste. Registre se a duplicação aparece fora do OBS.
2. Deixe apenas uma instância da fonte na cena. Verifique cópias de cenas, cenas aninhadas e camadas onde o mesmo endereço possa estar presente.
3. Adicione um log com o identificador do evento nas etapas de recebimento, enfileiramento e exibição. Assim ficará visível onde a quantidade de objetos aumenta.
4. Localize todas as chamadas de socket.on e addEventListener. Verifique se os manipuladores antigos são removidos via socket.off e removeEventListener com a mesma referência de função.
5. Verifique a reconexão: se o socket antigo é fechado, se o timer antigo é cancelado e se uma nova inscrição não é criada sobre a anterior.
6. Adicione a verificação do identificador único da doação antes da fila, depois reinicie completamente a fonte e repita o teste com um único evento.

Se a aba separada receber o evento uma vez e o OBS mostrar dois alertas, procure a segunda instância da fonte ou duplicação nas cenas. Se o evento chegar duas vezes já na aba separada, verifique inscrições, conexões e entrega pelo servidor. Se o recebimento e a fila forem registrados uma vez, mas a tela mostrar duas notificações, o problema está na camada visual.