Pourquoi un seul don déclenche deux alertes après la mise à jour d'une source navigateur

Pourquoi un seul don déclenche deux alertes

Après la mise à jour d'une source navigateur, la page redémarre. Le script se reconnecte au serveur, s'abonne aux événements et crée des gestionnaires pour afficher les notifications. Si l'ancien gestionnaire n'est pas supprimé ou si deux connexions fonctionnent en même temps, un seul événement de don est traité plusieurs fois.

La mise à jour elle-même n'est pas forcément la cause de la panne. Elle ne fait souvent que révéler une erreur dans la logique de connexion. Par exemple, la fonction d'initialisation peut se lancer au chargement de la page, puis lors du rétablissement de la connexion, et encore une fois après la réception d'un message de service. Chaque lancement ajoute un nouvel abonnement à l'événement donation.

Résultat : le serveur envoie un seul objet de don, mais le navigateur appelle deux fois la même fonction. Il arrive aussi que la duplication se produise côté serveur : l'application considère la nouvelle connexion comme un destinataire distinct et envoie l'événement à l'ancienne et à la nouvelle session. Il faut donc d'abord déterminer où apparaît le doublon : dans la source, dans le gestionnaire ou au stade de l'affichage.

Comment localiser l'origine du doublon

Commencez par un test simple. Ouvrez le lien de la source navigateur dans une fenêtre ou un onglet séparé, ne laissez qu'une seule instance de la page et envoyez un événement de test. Si l'alerte n'apparaît qu'une fois, la cause est probablement liée aux réglages de la scène ou à plusieurs instances de la source. Si le doublon apparaît déjà dans un onglet séparé, examinez le code de la page et le mécanisme d'abonnement.

Il est utile de diviser le traitement du don en plusieurs étapes : réception de l'événement, vérification de l'événement, mise en file de l'alerte et rendu. Affichez temporairement une marque à chaque étape dans le journal ou la console. Si l'entrée de réception apparaît deux fois, le problème se situe avant la couche visuelle. Si l'événement est reçu une fois mais que la file contient deux éléments, l'erreur vient du gestionnaire. Si la file ne contient qu'un élément mais que l'écran affiche deux alertes, vérifiez la fonction d'affichage et le conteneur HTML.

Pour le diagnostic, ajoutez à chaque événement son identifiant s'il est transmis dans les données du don. Notez cet identifiant à la réception et avant l'affichage. Un même identifiant dans deux appels montre qu'un seul événement a été traité plusieurs fois. Deux identifiants différents indiquent deux livraisons, à analyser séparément.

Ne vous contentez pas de vérifier le nombre d'onglets. Dans OBS, deux instances peuvent apparaître après la copie d'une scène, l'ajout d'une scène imbriquée ou l'ajout répété d'une source navigateur avec la même adresse. Il arrive qu'une source reste dans un calque séparé et qu'une seconde soit ajoutée par-dessus. Visuellement, cela ressemble à une double alerte, alors que l'événement n'est arrivé qu'une fois.

Réabonnement après reconnexion

La cause la plus fréquente est que le gestionnaire est ajouté à chaque connexion, mais n'est pas retiré lors de la déconnexion. En simplifié, le problème ressemble à ceci : la fonction lance socket.on avec un gestionnaire d'affichage d'alerte, puis la connexion est interrompue, l'application se reconnecte et répète socket.on. Désormais, un seul don entrant déclenche deux fonctions. À la reconnexion suivante, il peut y en avoir encore plus.

La même erreur se produit avec un addEventListener classique. Si la fonction d'initialisation est appelée plusieurs fois, le navigateur ajoute plusieurs écouteurs pour le même événement. Le contrôle par un indicateur « initialisation déjà effectuée » ne suffit pas toujours : lors d'un rechargement complet de la page, les variables sont réinitialisées, mais lors d'une reconnexion au sein de la même page, le problème persiste.

L'abonnement doit être créé une seule fois pour le cycle de vie de la connexion, et l'ancien abonnement doit être explicitement supprimé avant le nouveau. Pour les gestionnaires d'événements, on utilise removeEventListener avec la même référence de fonction que celle transmise lors de la connexion. Pour les bibliothèques avec sockets, il faut généralement une méthode off, unsubscribe ou un moyen équivalent de désabonnement.

Un schéma minimal pour un socket peut ressembler à ceci : 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);

Ce qui importe ici, ce n'est pas la bibliothèque précise, mais l'ordre des opérations. Le gestionnaire est stocké dans une variable, ce qui permet de le retirer avec la même référence. Avant un nouvel abonnement, l'ancien est supprimé, et lors de la fermeture de la page ou de l'arrêt de la source, cleanup est exécuté. Si un nouveau socket est créé à chaque lancement, il faut d'abord fermer l'ancien et seulement ensuite créer le nouveau. Sinon, les deux connexions peuvent continuer à recevoir les mêmes données.

Lors d'une reconnexion, fermez également l'ancienne connexion et effacez les minuteries associées. Sinon, l'ancien socket peut continuer à recevoir des données pendant que le nouveau fonctionne déjà. Cela se produit particulièrement souvent si le code lance une nouvelle minuterie de reconnexion sans annuler la précédente.

Ce qu'il faut vérifier dans OBS et la source navigateur

Si une fenêtre séparée n'affiche l'alerte qu'une fois, passez à la scène. Arrêtez l'aperçu, supprimez temporairement les calques superflus et ne laissez qu'une seule source navigateur. Vérifiez ensuite le comportement sur la scène concernée. Ce test est plus rapide que de vérifier toutes les scènes et tous les filtres en même temps.

• Cherchez deux sources avec la même adresse de page.
• Vérifiez les copies de scènes et les scènes imbriquées où le même overlay peut se trouver.
• Assurez-vous que l'alerte ne s'affiche pas simultanément via la source navigateur et un autre calque contenant la même page.
• Après avoir modifié les réglages, redémarrez complètement la source, et pas seulement en changeant de scène.

Il arrive qu'un ancien onglet de source navigateur reste dans OBS après la mise à jour de l'URL ou des paramètres. Fermer puis rajouter la source permet de tester l'hypothèse, mais ne remplace pas la correction du code. Si le problème revient après chaque mise à jour, cherchez une réinscription du gestionnaire ou une double connexion.

Tenez également compte du délai de déconnexion. Lors d'une mise à jour, l'ancienne session peut ne pas se fermer instantanément. Si le serveur la considère active pendant quelques secondes, un événement arrivé pendant cet intervalle peut toucher deux sessions. Une logique serveur normale doit supprimer les connexions inactives et ne pas laisser d'abonnement après la fermeture de la page.

Protection contre la double livraison d'un même événement

Même lorsque la source navigateur fonctionne correctement, un événement peut parfois être livré à nouveau. Cela peut se produire lors du rétablissement d'une connexion, du renvoi d'un message ou d'une défaillance entre la réception de l'événement et la confirmation de son traitement. Le gestionnaire d'alerte doit donc résister aux répétitions.

La meilleure méthode consiste à vérifier l'identifiant unique du don. Avant de placer l'événement en file, enregistrez son identifiant dans un ensemble d'événements déjà traités. Si cet identifiant a déjà été vu, le doublon doit être ignoré. La liste doit être conservée pendant une durée limitée pour ne pas croître indéfiniment.

N'utilisez pas uniquement le montant, le nom de l'expéditeur ou le texte du message pour cela. Deux dons différents peuvent avoir des données identiques. La vérification par l'heure n'est pas non plus fiable : plusieurs dons différents peuvent arriver presque simultanément. S'il n'y a pas d'identifiant, vous pouvez temporairement comparer une combinaison de champs et l'heure, mais c'est une solution de secours qui risque de fusionner à tort deux événements.

La protection contre les doublons doit se trouver avant l'affichage de l'alerte, et non à l'intérieur de l'animation. Sinon, le second appel ajoutera quand même un élément sur la page, jouera le son ou ajoutera une entrée supplémentaire dans la file. Contrôlez séparément la file : un événement doit y être ajouté une seule fois, et un appel répété ne doit pas lancer une seconde file indépendante.

Si l'événement est transmis entre plusieurs onglets ou composants, vérifiez qu'il n'est pas traité par plusieurs destinataires à la fois. Un canal de messages commun peut être connecté à plusieurs gestionnaires. Dans ce cas, il faut soit ne garder qu'un seul consommateur, soit définir explicitement quel composant est chargé d'afficher l'alerte.

Pourquoi vider le cache ne suffit pas toujours

Après la mise à jour d'une source navigateur, on conseille souvent de vider le cache. Cela peut corriger la situation si une ancienne version du script a été chargée, mais le cache ne supprime pas les gestionnaires superflus dans une page déjà en cours d'exécution et ne ferme pas la seconde copie de la source. Si le doublon se répète systématiquement après chaque reconnexion, la cause se trouve presque certainement dans la logique de connexion ou dans la structure de la scène.

Vérifiez que la nouvelle version des fichiers est bien chargée. Modifiez temporairement l'adresse de la ressource ou utilisez le mécanisme de mise à jour prévu, puis redémarrez la source navigateur. Refaites ensuite le test avec une seule fenêtre et une seule instance de la source. N'ajoutez pas de paramètres aléatoires au lien en permanence : cela peut créer de nombreuses variantes de cache et compliquer le diagnostic.

Si un cache intermédiaire ou un service worker est utilisé, il peut lui aussi servir un script obsolète. Dans ce cas, comparez la version du fichier chargé avec celle que vous attendez. Mais même avec un ancien fichier, il faut éliminer la cause du réabonnement, sinon le problème réapparaîtra après la mise à jour suivante.

Ce qu'il faut vérifier dans le code de l'alerte

Cherchez d'abord tous les endroits où sont appelés socket.on, addEventListener, les fonctions de connexion et le lancement de la file. Parfois, le problème ne vient pas d'un seul gestionnaire, mais du fait que deux modules différents écoutent indépendamment l'événement donation et que chacun lance son propre affichage.

Vérifiez ensuite le cycle de vie du composant si l'alerte est affichée via un framework. L'abonnement est placé dans un effet ou un bloc équivalent et une fonction de nettoyage est renvoyée. Il ne faut pas créer un nouveau gestionnaire à chaque mise à jour d'état sans supprimer le précédent. En JavaScript classique, il est important de conserver la référence au socket actif et au gestionnaire courant afin de pouvoir les fermer correctement à l'arrêt de la page.

Vérifiez les minuteries de reconnexion. Une nouvelle minuterie ne doit pas se lancer par-dessus l'ancienne. Sinon, après plusieurs coupures, des tentatives de connexion parallèles se créent, et avec elles des abonnements supplémentaires. Chaque minuterie doit être nettoyée via clearTimeout ou clearInterval si elle n'est plus nécessaire.

Examinez séparément le code qui affiche l'alerte. Il ne doit pas à la fois ajouter un élément à la file et appeler immédiatement la fonction d'affichage pour le même objet. Vérifiez aussi que l'animation ne se relance pas lors d'un changement d'état de l'élément. Si le journal montre une réception et une entrée en file, mais que l'écran affiche deux notifications, c'est précisément ici qu'il faut chercher.

Liste de contrôle du diagnostic : que faire dans l'ordre

1. Ouvrez l'URL de la source navigateur dans un onglet séparé et envoyez un don de test. Notez si le doublon apparaît en dehors d'OBS.
2. Ne laissez qu'une seule instance de la source dans la scène. Vérifiez les copies de scènes, les scènes imbriquées et les calques où la même adresse peut se trouver.
3. Ajoutez un journal avec l'identifiant de l'événement aux étapes de réception, de mise en file et d'affichage. Vous verrez ainsi où le nombre d'objets augmente.
4. Trouvez tous les appels à socket.on et addEventListener. Vérifiez que les anciens gestionnaires sont retirés via socket.off et removeEventListener avec la même référence de fonction.
5. Vérifiez la reconnexion : l'ancien socket est-il fermé, l'ancienne minuterie est-elle annulée, et un nouvel abonnement n'est-il pas créé par-dessus l'ancien ?
6. Ajoutez une vérification de l'identifiant unique du don avant la file, puis redémarrez complètement la source et refaites le test avec un seul événement.

Si un onglet séparé ne reçoit l'événement qu'une fois mais qu'OBS affiche deux alertes, cherchez une seconde instance de la source ou une duplication dans les scènes. Si l'événement arrive deux fois déjà dans un onglet séparé, vérifiez les abonnements, les connexions et la livraison côté serveur. Si la réception et la mise en file ne sont enregistrées qu'une fois mais que l'écran affiche deux notifications, le problème se situe dans la couche visuelle.