Por qué una sola donación provoca dos alertas tras actualizar la fuente de navegador

Por qué una sola donación provoca dos alertas

Tras actualizar la fuente de navegador, la página se inicia de nuevo. El script vuelve a conectarse al servidor, se suscribe a los eventos y crea los controladores para mostrar las notificaciones. Si el controlador antiguo no se ha eliminado o hay dos conexiones activas al mismo tiempo, un mismo evento de donación se procesa varias veces.

La actualización en sí no es necesariamente la causa del fallo. A menudo solo pone de manifiesto un error en la lógica de conexión. Por ejemplo, la función de inicialización puede ejecutarse al cargar la página, luego al restablecerse la conexión y otra vez tras recibir un mensaje de servicio. Cada ejecución añade una nueva suscripción al evento donation.

Como resultado, el servidor envía un solo objeto de donación, pero el navegador llama a la misma función dos veces. A veces la duplicación se produce en el lado del servidor: la aplicación considera la nueva conexión como un destinatario distinto y envía el evento tanto a la sesión antigua como a la nueva. Por eso primero hay que determinar dónde aparece la repetición: en la fuente, en el controlador o en la etapa de visualización.

Cómo localizar el punto donde surge el duplicado

Empieza con una prueba sencilla. Abre el enlace de la fuente de navegador en una ventana o pestaña aparte, deja solo una instancia de la página y envía un evento de prueba. Si la alerta aparece una sola vez, lo más probable es que la causa esté relacionada con la configuración de la escena o con varias instancias de la fuente. Si ya se duplica en una pestaña aparte, revisa el código de la página y el mecanismo de suscripción.

Resulta útil dividir el procesamiento de la donación en varias etapas: recepción del evento, verificación del evento, puesta en cola de la alerta y renderizado. En el registro o en la consola, muestra temporalmente una marca en cada etapa. Si el registro de recepción aparece dos veces, el problema está antes de la capa visual. Si el evento se recibe una vez pero hay dos elementos en la cola, el error está en el controlador. Si la cola contiene un solo elemento pero en pantalla hay dos alertas, revisa la función de visualización y el contenedor HTML.

Para el diagnóstico, añade a cada evento su identificador, si se transmite en los datos de la donación. Registra ese identificador al recibirlo y antes de mostrarlo. Un mismo identificador en dos llamadas indica que un evento se ha procesado de nuevo. Dos identificadores distintos indican dos entregas que hay que analizar por separado.

No revises solo el número de pestañas. En OBS pueden aparecer dos instancias tras copiar la escena, añadir una escena anidada o volver a añadir la fuente de navegador con la misma dirección. A veces una fuente permanece en una capa aparte y la segunda se añade encima. Visualmente parece una alerta doble, aunque el evento haya llegado una sola vez.

Suscripción repetida tras la reconexión

La causa más frecuente es que el controlador se añade en cada conexión, pero no se elimina al desconectarse. Simplificando, el problema es así: la función ejecuta socket.on con el controlador que muestra la alerta, luego la conexión se interrumpe, la aplicación se conecta de nuevo y repite socket.on. Después de eso, una sola donación entrante llama a dos funciones. En la siguiente reconexión puede haber aún más.

El mismo error se da con addEventListener normal. Si la función de inicialización se ejecuta varias veces, el navegador añade varios escuchadores del mismo evento. La comprobación de una bandera de «inicialización ya realizada» no siempre ayuda: al actualizar la página por completo las variables se restablecen, y al reconectar dentro de la misma página el problema persiste.

La suscripción debe crearse una sola vez por ciclo de vida de la conexión, y la suscripción antigua debe eliminarse explícitamente antes de la nueva. Para los controladores de eventos se usa removeEventListener y la misma referencia a la función que se pasó al conectar. Para las bibliotecas con sockets normalmente hace falta el método off, unsubscribe o una forma equivalente de desconexión.

Un esquema mínimo para el socket podría ser así: 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);

Aquí lo importante no es la biblioteca concreta, sino el orden de las acciones. El controlador se guarda en una variable, por lo que se puede eliminar con la misma referencia. Antes de la nueva suscripción se elimina la antigua, y al cerrar la página o detener la fuente se ejecuta cleanup. Si en cada inicio se crea un socket nuevo, primero hay que cerrar el antiguo y solo después crear el nuevo. De lo contrario, ambas conexiones pueden seguir recibiendo los mismos datos.

Al reconectar, cierra también la conexión antigua y limpia los temporizadores asociados. De lo contrario, el socket antiguo puede seguir recibiendo datos mientras el nuevo ya está funcionando. Esto ocurre especialmente si el código inicia un nuevo temporizador de reconexión sin cancelar el anterior.

Qué revisar en OBS y en la fuente de navegador

Si una ventana aparte muestra la alerta una sola vez, pasa a la escena. Detén la vista previa, elimina temporalmente las capas sobrantes y deja una sola fuente de navegador. Después comprueba el comportamiento en la escena correspondiente. Esta prueba es más rápida que revisar todas las escenas y filtros a la vez.

• Busca dos fuentes con la misma dirección de página.
• Revisa las copias de escenas y las escenas anidadas donde pueda estar el mismo overlay.
• Asegúrate de que la alerta no se muestra a la vez desde la fuente de navegador y desde otra capa con la misma página.
• Tras cambiar la configuración, reinicia por completo la fuente, no solo cambies de escena.

A veces en OBS queda una pestaña antigua de la fuente de navegador tras actualizar la URL o los parámetros. Cerrar y volver a añadir la fuente ayuda a comprobar la hipótesis, pero no sustituye la corrección del código. Si el problema vuelve tras cada actualización, busca un registro repetido del controlador o una conexión doble.

Ten en cuenta también el retraso de desconexión. Al actualizar, la sesión antigua puede no cerrarse al instante. Si el servidor la considera activa durante unos segundos, el evento que llegue en ese intervalo puede acabar en dos sesiones. La lógica normal del servidor debería eliminar las conexiones inactivas y no dejar la suscripción tras cerrar la página.

Protección contra la reentrega de un mismo evento

Incluso con un funcionamiento correcto de la fuente de navegador, a veces un evento puede entregarse de nuevo. Esto es posible al restablecerse la conexión, al reenviarse un mensaje o por un fallo entre la recepción del evento y la confirmación de su procesamiento. Por eso el controlador de la alerta debe ser resistente a las repeticiones.

La mejor forma es comprobar el identificador único de la donación. Antes de poner el evento en cola, guarda su identificador en un conjunto de eventos ya procesados. Si ese identificador ya ha aparecido, hay que omitir la repetición. La lista debe conservarse durante un tiempo limitado para que no crezca sin fin.

No uses para esto solo el importe, el nombre del remitente o el texto del mensaje. Dos donaciones distintas pueden tener los mismos datos. La comprobación por hora tampoco es fiable: varias donaciones diferentes pueden llegar casi al mismo tiempo. Si no hay identificador, se puede comparar temporalmente una combinación de campos y la hora, pero es una opción de reserva con el riesgo de unir por error dos eventos.

La protección contra duplicados debe estar antes de mostrar la alerta, no dentro de la animación. De lo contrario, la segunda llamada igualmente añadirá un elemento a la página, reproducirá el sonido o pondrá otro registro en la cola. Controla la cola por separado: un evento debe añadirse a ella una sola vez, y una llamada repetida no debe iniciar una segunda cola independiente.

Si el evento se transmite entre varias pestañas o componentes, comprueba si lo procesan varios destinatarios a la vez. Un mismo canal de mensajes compartido puede estar conectado a varios controladores. En ese caso hay que dejar un solo consumidor o definir explícitamente qué componente se encarga de mostrar la alerta.

Por qué limpiar la caché no siempre ayuda

Tras actualizar la fuente de navegador, a menudo se recomienda limpiar la caché. Esto puede corregir la situación si se cargó una versión antigua del script, pero la caché no elimina los controladores sobrantes en una página ya en funcionamiento ni cierra la segunda copia de la fuente. Si el duplicado se repite de forma estable tras cada reconexión, la causa está casi con seguridad en la lógica de conexión o en la estructura de la escena.

Comprueba si realmente se carga la nueva versión de los archivos. Cambia temporalmente la dirección del recurso o usa el mecanismo de actualización previsto, y luego reinicia la fuente de navegador. Después vuelve a hacer la prueba con una sola ventana y una sola instancia de la fuente. No añadas parámetros aleatorios al enlace de forma constante: puede crear muchas variantes de caché y complicar el diagnóstico.

Si se usa una caché intermedia o un service worker, también puede servir un script obsoleto. En ese caso, compara la versión del archivo cargado con la versión que esperas ver. Pero incluso con un archivo antiguo hay que eliminar la causa de la suscripción repetida, porque el problema volverá a aparecer tras la siguiente actualización.

Qué revisar en el código de la alerta

Primero localiza todos los lugares donde se llaman socket.on, addEventListener, las funciones de conexión y el inicio de la cola. A veces el problema no está en un solo controlador, sino en que dos módulos distintos escuchan el evento donation de forma independiente y cada uno inicia su propia visualización.

Luego revisa el ciclo de vida del componente, si la alerta se muestra mediante un framework. La suscripción se coloca en un efecto o bloque similar y se devuelve una función de limpieza. No se puede crear un nuevo controlador en cada actualización de estado sin eliminar el anterior. En JavaScript normal es importante guardar la referencia al socket activo y al controlador actual para poder cerrarlos correctamente al detener la página.

Revisa los temporizadores de reconexión. Un nuevo temporizador no debe iniciarse sobre el antiguo. De lo contrario, tras varias interrupciones se crean intentos de conexión paralelos y, con ellos, suscripciones adicionales. Cada temporizador necesita una limpieza mediante clearTimeout o clearInterval si ya no es necesario.

Revisa por separado el código que muestra la alerta. No debe añadir el elemento a la cola y llamar a la vez a la función de visualización para el mismo objeto. Comprueba también si la animación se vuelve a iniciar al cambiar el estado del elemento. Si en el registro hay una sola recepción y un solo registro en la cola, pero en pantalla aparecen dos notificaciones, es aquí donde hay que buscar.

Lista de comprobación del diagnóstico: qué hacer en orden

1. Abre la URL de la fuente de navegador en una pestaña aparte y envía una donación de prueba. Anota si el duplicado aparece fuera de OBS.
2. Deja en la escena solo una instancia de la fuente. Revisa las copias de escenas, las escenas anidadas y las capas donde pueda estar la misma dirección.
3. Añade un registro con el identificador del evento en las etapas de recepción, puesta en cola y visualización. Así se verá dónde aumenta el número de objetos.
4. Localiza todas las llamadas a socket.on y addEventListener. Comprueba si los controladores antiguos se eliminan mediante socket.off y removeEventListener con la misma referencia a la función.
5. Revisa la reconexión: si se cierra el socket antiguo, si se cancela el temporizador antiguo y si no se crea una nueva suscripción sobre la anterior.
6. Añade una comprobación del identificador único de la donación antes de la cola, luego reinicia por completo la fuente y repite la prueba con un solo evento.

Si una pestaña aparte recibe el evento una sola vez y OBS muestra dos alertas, busca la segunda instancia de la fuente o una duplicación en las escenas. Si el evento llega dos veces ya en una pestaña aparte, revisa las suscripciones, las conexiones y la entrega del servidor. Si la recepción y la cola se registran una sola vez, pero en pantalla aparecen dos notificaciones, el problema está en la capa visual.