Warum eine Donation nach dem Update der Browserquelle zwei Alerts auslöst

Warum eine Donation zwei Alerts auslöst

Nach dem Update der Browserquelle wird die Seite neu gestartet. Das Skript verbindet sich erneut mit dem Server, abonniert Ereignisse und erstellt Handler für die Anzeige von Benachrichtigungen. Wenn der alte Handler nicht entfernt wurde oder gleichzeitig zwei Verbindungen aktiv sind, wird ein Donation-Ereignis mehrfach verarbeitet.

Das Update selbst ist nicht unbedingt die Ursache des Fehlers. Oft macht es nur einen Fehler in der Verbindungslogik sichtbar. Beispielsweise kann die Initialisierungsfunktion beim Laden der Seite ausgeführt werden, dann beim Wiederherstellen der Verbindung und noch einmal nach dem Empfang einer Dienstnachricht. Jeder Start fügt ein neues Abonnement für das Ereignis donation hinzu.

Infolgedessen sendet der Server ein einziges Donation-Objekt, aber der Browser ruft dieselbe Funktion zweimal auf. Manchmal entsteht die Duplizierung auf der Serverseite: Die Anwendung betrachtet die neue Verbindung als separaten Empfänger und sendet das Ereignis sowohl an die alte als auch an die neue Sitzung. Deshalb muss zuerst festgestellt werden, wo die Wiederholung entsteht: in der Quelle, im Handler oder in der Anzeigephase.

Wie man die Stelle findet, an der das Duplikat entsteht

Beginne mit einem einfachen Test. Öffne den Link der Browserquelle in einem separaten Fenster oder Tab, lasse nur eine Instanz der Seite geöffnet und sende ein Testereignis. Wenn der Alert nur einmal erscheint, hängt die Ursache wahrscheinlich mit den Szeneneinstellungen oder mit mehreren Instanzen der Quelle zusammen. Wenn er bereits im separaten Tab dupliziert wird, prüfe den Seitencode und den Abonnementmechanismus.

Es ist hilfreich, die Verarbeitung der Donation in mehrere Phasen aufzuteilen: Empfang des Ereignisses, Prüfung des Ereignisses, Einreihung des Alerts in die Warteschlange und Darstellung. Gib im Protokoll oder in der Konsole vorübergehend an jeder Phase eine Markierung aus. Wenn der Eintrag über den Empfang zweimal erscheint, liegt das Problem vor der visuellen Ebene. Wenn das Ereignis einmal empfangen wird, aber zwei Elemente in der Warteschlange stehen, liegt der Fehler im Handler. Wenn die Warteschlange ein Element enthält, aber auf dem Bildschirm zwei Alerts erscheinen, prüfe die Anzeigefunktion und den HTML-Container.

Füge zur Diagnose jedem Ereignis seine Kennung hinzu, falls diese in den Donation-Daten übergeben wird. Notiere diese Kennung beim Empfang und vor der Anzeige. Dieselbe Kennung in zwei Aufrufen zeigt, dass ein Ereignis erneut verarbeitet wurde. Zwei unterschiedliche Kennungen deuten auf zwei Zustellungen hin, die separat untersucht werden müssen.

Prüfe nicht nur die Anzahl der Tabs. In OBS können zwei Instanzen entstehen, nachdem eine Szene kopiert, eine verschachtelte Szene hinzugefügt oder eine Browserquelle mit derselben Adresse erneut hinzugefügt wurde. Manchmal bleibt eine Quelle in einer separaten Ebene, während die zweite darüber hinzugefügt wird. Visuell sieht das wie ein doppelter Alert aus, obwohl das Ereignis nur einmal eingegangen ist.

Erneutes Abonnement nach dem Wiederverbinden

Die häufigste Ursache ist, dass der Handler bei jeder Verbindung hinzugefügt, aber beim Trennen nicht entfernt wird. Vereinfacht sieht das Problem so aus: Die Funktion startet socket.on mit einem Handler für die Alert-Anzeige, dann bricht die Verbindung ab, die Anwendung verbindet sich erneut und wiederholt socket.on. Danach löst eine eingehende Donation zwei Funktionen aus. Beim nächsten Wiederverbinden können es noch mehr werden.

Derselbe Fehler tritt auch mit einem normalen addEventListener auf. Wenn die Initialisierungsfunktion mehrmals aufgerufen wird, fügt der Browser mehrere Listener für dasselbe Ereignis hinzu. Die Prüfung eines Flags „Initialisierung bereits abgeschlossen“ hilft nicht immer: Bei einem vollständigen Neuladen der Seite werden die Variablen zurückgesetzt, und beim Wiederverbinden innerhalb derselben Seite bleibt das Problem bestehen.

Das Abonnement sollte einmal pro Lebenszyklus der Verbindung erstellt und das alte Abonnement vor dem neuen ausdrücklich entfernt werden. Für Ereignis-Handler verwendet man removeEventListener und dieselbe Funktionsreferenz, die bei der Verbindung übergeben wurde. Für Socket-Bibliotheken ist in der Regel eine Methode wie off, unsubscribe oder eine ähnliche Möglichkeit zum Abmelden erforderlich.

Ein minimales Schema für einen Socket kann so aussehen: 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);

Wichtig ist hier nicht die konkrete Bibliothek, sondern die Reihenfolge der Aktionen. Der Handler wird in einer Variablen gespeichert, damit er über dieselbe Referenz entfernt werden kann. Vor dem neuen Abonnement wird das alte entfernt, und beim Schließen der Seite oder beim Stoppen der Quelle wird cleanup ausgeführt. Wenn bei jedem Start ein neuer Socket erstellt wird, muss zuerst der alte geschlossen und erst danach der neue erstellt werden. Andernfalls können beide Verbindungen weiterhin dieselben Daten empfangen.

Beim Wiederverbinden sollte außerdem die alte Verbindung geschlossen und zugehörige Timer gelöscht werden. Sonst kann der alte Socket weiterhin Daten empfangen, während der neue bereits läuft. Besonders häufig passiert das, wenn der Code einen neuen Timer für die erneute Verbindung startet, ohne den vorherigen abzubrechen.

Was in OBS und in der Browserquelle zu prüfen ist

Wenn ein separates Fenster den Alert nur einmal anzeigt, wechsle zur Szene. Stoppe die Vorschau, entferne vorübergehend überflüssige Ebenen und lasse nur eine Browserquelle übrig. Prüfe dann das Verhalten in der gewünschten Szene. Dieser Test ist schneller als die gleichzeitige Prüfung aller Szenen und Filter.

• Suche nach zwei Quellen mit derselben Seitenadresse.
• Prüfe Szenenkopien und verschachtelte Szenen, in denen sich dasselbe Overlay befinden kann.
• Stelle sicher, dass der Alert nicht gleichzeitig von der Browserquelle und einer anderen Ebene mit derselben Seite ausgegeben wird.
• Starte die Quelle nach Änderungen der Einstellungen vollständig neu und wechsle nicht nur die Szene.

Manchmal bleibt in OBS nach dem Aktualisieren der URL oder der Parameter ein alter Tab der Browserquelle erhalten. Das Schließen und erneute Hinzufügen der Quelle hilft, die Hypothese zu prüfen, ersetzt aber nicht die Korrektur des Codes. Wenn das Problem nach jedem Update wiederkehrt, suche nach einer erneuten Registrierung des Handlers oder einer doppelten Verbindung.

Berücksichtige auch die Verzögerung beim Trennen. Beim Aktualisieren wird die alte Sitzung möglicherweise nicht sofort geschlossen. Wenn der Server sie für einige Sekunden als aktiv betrachtet, kann ein Ereignis, das in diesem Zeitraum eintrifft, in zwei Sitzungen gelangen. Eine korrekte Serverlogik sollte inaktive Verbindungen entfernen und kein Abonnement nach dem Schließen der Seite hinterlassen.

Schutz vor erneuter Zustellung eines Ereignisses

Selbst bei korrekter Funktion der Browserquelle kann ein Ereignis manchmal erneut zugestellt werden. Das ist möglich bei der Wiederherstellung der Verbindung, beim erneuten Senden einer Nachricht oder bei einem Fehler zwischen dem Empfang des Ereignisses und der Bestätigung seiner Verarbeitung. Deshalb muss der Alert-Handler gegenüber Wiederholungen robust sein.

Die beste Methode ist die Prüfung einer eindeutigen Donation-Kennung. Speichere vor dem Einreihen des Ereignisses in die Warteschlange seine Kennung in einem Satz bereits verarbeiteter Ereignisse. Wenn diese Kennung bereits vorgekommen ist, muss die Wiederholung übersprungen werden. Die Liste sollte nur für eine begrenzte Zeit gespeichert werden, damit sie nicht unbegrenzt wächst.

Verwende dafür nicht nur den Betrag, den Namen des Absenders oder den Nachrichtentext. Zwei verschiedene Donations können dieselben Daten haben. Auch die Prüfung anhand der Zeit ist unzuverlässig: Mehrere verschiedene Donations können nahezu gleichzeitig eintreffen. Wenn keine Kennung vorhanden ist, kann man vorübergehend eine Kombination aus Feldern und Zeit vergleichen, aber das ist eine Notlösung mit dem Risiko, zwei Ereignisse fälschlich zusammenzuführen.

Der Schutz vor Duplikaten sollte vor der Anzeige des Alerts erfolgen und nicht innerhalb der Animation. Andernfalls fügt der zweite Aufruf trotzdem ein Element zur Seite hinzu, spielt den Ton ab oder stellt einen weiteren Eintrag in die Warteschlange. Überwache die Warteschlange separat: Ein Ereignis sollte nur einmal in sie eingereiht werden, und ein erneuter Aufruf darf keine zweite unabhängige Warteschlange starten.

Wenn ein Ereignis zwischen mehreren Tabs oder Komponenten weitergegeben wird, prüfe, ob es nicht von mehreren Empfängern gleichzeitig verarbeitet wird. Ein gemeinsamer Nachrichtenkanal kann mit mehreren Handlern verbunden sein. In diesem Fall sollte entweder nur ein Verbraucher bleiben oder ausdrücklich festgelegt werden, welche Komponente für die Anzeige des Alerts zuständig ist.

Warum das Leeren des Caches nicht immer hilft

Nach dem Update der Browserquelle wird oft empfohlen, den Cache zu leeren. Das kann die Situation beheben, wenn eine alte Version des Skripts geladen wurde, aber der Cache entfernt keine überflüssigen Handler in einer bereits laufenden Seite und schließt auch nicht die zweite Kopie der Quelle. Wenn das Duplikat nach jedem Wiederverbinden stabil auftritt, liegt die Ursache fast sicher in der Verbindungslogik oder in der Struktur der Szene.

Prüfe, ob tatsächlich die neue Version der Dateien geladen wird. Ändere vorübergehend die Adresse der Ressource oder nutze den vorgesehenen Aktualisierungsmechanismus und starte dann die Browserquelle neu. Führe danach erneut den Test mit einem Fenster und einer Instanz der Quelle durch. Füge nicht ständig zufällige Parameter zur URL hinzu: Das kann viele Cache-Varianten erzeugen und die Diagnose erschweren.

Wenn ein Zwischen-Cache oder ein Service Worker verwendet wird, kann auch dieser ein veraltetes Skript ausliefern. Vergleiche in diesem Fall die Version der geladenen Datei mit der Version, die du erwartest. Aber selbst bei einer alten Datei muss die Ursache des erneuten Abonnements behoben werden, sonst tritt das Problem nach dem nächsten Update wieder auf.

Was im Code des Alerts zu prüfen ist

Finde zuerst alle Stellen, an denen socket.on, addEventListener, Verbindungsfunktionen und der Start der Warteschlange aufgerufen werden. Manchmal liegt das Problem nicht in einem Handler, sondern darin, dass zwei verschiedene Module unabhängig voneinander das Ereignis donation abhören und jeweils ihre eigene Anzeige starten.

Prüfe dann den Lebenszyklus der Komponente, wenn der Alert über ein Framework ausgegeben wird. Das Abonnement wird in einem Effekt oder einem ähnlichen Block platziert und gibt eine Bereinigungsfunktion zurück. Es ist nicht zulässig, bei jeder Statusaktualisierung einen neuen Handler zu erstellen, ohne den vorherigen zu entfernen. In normalem JavaScript ist es wichtig, die Referenz auf den aktiven Socket und den aktuellen Handler zu speichern, damit sie beim Stoppen der Seite korrekt geschlossen werden können.

Prüfe die Timer für die erneute Verbindung. Ein neuer Timer darf nicht über einem alten gestartet werden. Andernfalls entstehen nach mehreren Abbrüchen parallele Verbindungsversuche und damit zusätzliche Abonnements. Für jeden Timer ist eine Bereinigung über clearTimeout oder clearInterval erforderlich, wenn er nicht mehr benötigt wird.

Sieh dir separat den Code an, der den Alert anzeigt. Er darf nicht gleichzeitig ein Element zur Warteschlange hinzufügen und sofort die Anzeigefunktion für dasselbe Objekt aufrufen. Prüfe außerdem, ob die Animation bei einer Änderung des Zustands des Elements erneut startet. Wenn im Protokoll ein Empfang und ein Eintrag in der Warteschlange stehen, auf dem Bildschirm aber zwei Benachrichtigungen erscheinen, muss genau hier gesucht werden.

Diagnose-Checkliste: Was in welcher Reihenfolge zu tun ist

1. Öffne die URL der Browserquelle in einem separaten Tab und sende eine Test-Donation. Halte fest, ob das Duplikat außerhalb von OBS erscheint.
2. Lasse in der Szene nur eine Instanz der Quelle übrig. Prüfe Szenenkopien, verschachtelte Szenen und Ebenen, in denen sich dieselbe Adresse befinden kann.
3. Füge ein Protokoll mit der Ereignis-Kennung in den Phasen Empfang, Einreihung in die Warteschlange und Anzeige hinzu. So wird sichtbar, wo die Anzahl der Objekte zunimmt.
4. Finde alle Aufrufe von socket.on und addEventListener. Prüfe, ob alte Handler über socket.off und removeEventListener mit derselben Funktionsreferenz entfernt werden.
5. Prüfe das Wiederverbinden: Wird der alte Socket geschlossen, wird der alte Timer abgebrochen und wird kein neues Abonnement über dem bisherigen erstellt?
6. Füge vor der Warteschlange eine Prüfung der eindeutigen Donation-Kennung hinzu, starte dann die Quelle vollständig neu und wiederhole den Test mit einem Ereignis.

Wenn ein separater Tab das Ereignis einmal empfängt, OBS aber zwei Alerts anzeigt, suche nach der zweiten Instanz der Quelle oder nach einer Duplizierung in den Szenen. Wenn das Ereignis bereits in einem separaten Tab zweimal eintrifft, prüfe Abonnements, Verbindungen und die serverseitige Zustellung. Wenn Empfang und Warteschlange einmal erfasst werden, auf dem Bildschirm aber zwei Benachrichtigungen erscheinen, liegt das Problem in der visuellen Ebene.