Perché una singola donazione genera due alert dopo l'aggiornamento della sorgente browser

Perché una singola donazione genera due alert

Dopo l'aggiornamento della sorgente browser la pagina si avvia di nuovo. Lo script si riconnette al server, si sottoscrive agli eventi e crea i gestori per mostrare le notifiche. Se il vecchio gestore non viene rimosso o se sono attive contemporaneamente due connessioni, un singolo evento di donazione viene elaborato più volte.

L'aggiornamento in sé non è necessariamente la causa del guasto. Spesso fa solo emergere un errore nella logica di connessione. Ad esempio, la funzione di inizializzazione può essere eseguita al caricamento della pagina, poi al ripristino della connessione e ancora una volta dopo la ricezione di un messaggio di servizio. Ogni esecuzione aggiunge una nuova sottoscrizione all'evento donation.

Di conseguenza il server invia un solo oggetto donazione, ma il browser richiama due volte la stessa funzione. A volte la duplicazione avviene lato server: l'applicazione considera la nuova connessione un destinatario separato e invia l'evento sia alla vecchia che alla nuova sessione. Per questo bisogna prima stabilire dove compare la ripetizione: nella sorgente, nel gestore o nella fase di visualizzazione.

Come individuare il punto in cui nasce il duplicato

Inizia con un test semplice. Apri il link della sorgente browser in una finestra o scheda separata, lascia una sola istanza della pagina e invia un evento di test. Se l'alert compare una sola volta, la causa è probabilmente legata alle impostazioni della scena o a più istanze della sorgente. Se invece si duplica già nella scheda separata, controlla il codice della pagina e il meccanismo di sottoscrizione.

È utile suddividere l'elaborazione della donazione in più fasi: ricezione dell'evento, verifica dell'evento, inserimento dell'alert in coda e rendering. Nel log o nella console stampa temporaneamente un marcatore a ogni fase. Se la registrazione della ricezione compare due volte, il problema è prima del livello visivo. Se l'evento viene ricevuto una volta ma in coda ci sono due elementi, l'errore è nel gestore. Se la coda contiene un solo elemento ma sullo schermo ci sono due alert, controlla la funzione di visualizzazione e il contenitore HTML.

Per la diagnosi aggiungi a ogni evento il suo identificatore, se viene trasmesso nei dati della donazione. Registra questo identificatore al momento della ricezione e prima della visualizzazione. Lo stesso identificatore in due chiamate indica che un singolo evento è stato elaborato più volte. Due identificatori diversi indicano due consegne, da analizzare separatamente.

Non controllare solo il numero di schede. In OBS due istanze possono comparire dopo aver copiato una scena, aver aggiunto una scena annidata o aver aggiunto di nuovo una sorgente browser con lo stesso indirizzo. A volte una sorgente resta in un livello separato e la seconda viene aggiunta sopra di essa. Visivamente sembra un doppio alert, anche se l'evento è arrivato una sola volta.

Sottoscrizione ripetuta dopo la riconnessione

La causa più frequente è che il gestore viene aggiunto a ogni connessione ma non rimosso alla disconnessione. In forma semplificata il problema è questo: la funzione esegue socket.on con il gestore che mostra l'alert, poi la connessione cade, l'applicazione si riconnette e ripete socket.on. Dopo di ciò una singola donazione in entrata richiama due funzioni. Alla riconnessione successiva possono diventare ancora di più.

Lo stesso errore si verifica con il normale addEventListener. Se la funzione di inizializzazione viene eseguita più volte, il browser aggiunge più listener allo stesso evento. Il controllo con un flag "inizializzazione già eseguita" non sempre aiuta: con un aggiornamento completo della pagina le variabili vengono azzerate, mentre con una riconnessione all'interno della stessa pagina il problema persiste.

La sottoscrizione va creata una sola volta per il ciclo di vita della connessione, e quella vecchia va rimossa esplicitamente prima della nuova. Per i gestori di eventi si usa removeEventListener con lo stesso riferimento alla funzione passato al momento della sottoscrizione. Per le librerie con socket di solito serve il metodo off, unsubscribe o un modo equivalente di annullamento.

Uno schema minimo per il socket può essere questo: 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);

Qui non conta la libreria specifica, ma l'ordine delle operazioni. Il gestore è memorizzato in una variabile, quindi può essere rimosso con lo stesso riferimento. Prima della nuova sottoscrizione si elimina quella vecchia, e alla chiusura della pagina o all'arresto della sorgente si esegue cleanup. Se a ogni avvio viene creato un nuovo socket, bisogna prima chiudere quello vecchio e solo dopo crearne uno nuovo. Altrimenti entrambe le connessioni possono continuare a ricevere gli stessi dati.

Alla riconnessione chiudi anche la vecchia connessione e cancella i timer associati. Altrimenti il vecchio socket può continuare a ricevere dati mentre quello nuovo è già attivo. Questo accade particolarmente spesso se il codice avvia un nuovo timer di riconnessione senza annullare il precedente.

Cosa controllare in OBS e nella sorgente browser

Se in una finestra separata l'alert compare una sola volta, passa alla scena. Ferma l'anteprima, rimuovi temporaneamente i livelli superflui e lascia una sola sorgente browser. Poi verifica il comportamento nella scena desiderata. Questo test è più rapido del controllo simultaneo di tutte le scene e dei filtri.

• Cerca due sorgenti con lo stesso indirizzo della pagina.
• Controlla le copie delle scene e le scene annidate in cui potrebbe trovarsi lo stesso overlay.
• Assicurati che l'alert non venga mostrato contemporaneamente dalla sorgente browser e da un altro livello con la stessa pagina.
• Dopo aver modificato le impostazioni riavvia completamente la sorgente, non solo cambiare scena.

A volte in OBS resta una vecchia scheda della sorgente browser dopo l'aggiornamento dell'URL o dei parametri. Chiudere e riaggiungere la sorgente aiuta a verificare l'ipotesi, ma non sostituisce la correzione del codice. Se dopo ogni aggiornamento il problema ritorna, cerca una registrazione ripetuta del gestore o una doppia connessione.

Tieni conto anche del ritardo di disconnessione. Durante l'aggiornamento la vecchia sessione potrebbe non chiudersi istantaneamente. Se il server per alcuni secondi la considera attiva, un evento che arriva in questo intervallo può finire in due sessioni. Una logica server corretta dovrebbe rimuovere le connessioni inattive e non lasciare la sottoscrizione dopo la chiusura della pagina.

Protezione dalla doppia consegna di un singolo evento

Anche con una sorgente browser funzionante, un singolo evento può a volte essere consegnato di nuovo. Questo può accadere al ripristino della connessione, al reinvio di un messaggio o in caso di errore tra la ricezione dell'evento e la conferma della sua elaborazione. Per questo il gestore dell'alert deve essere resistente alle ripetizioni.

Il modo migliore è verificare l'identificatore univoco della donazione. Prima di inserire l'evento in coda, salva il suo identificatore in un insieme di eventi già elaborati. Se l'identificatore è già comparso, la ripetizione va ignorata. L'elenco va conservato per un tempo limitato, così non cresce all'infinito.

Non usare a questo scopo solo l'importo, il nome del mittente o il testo del messaggio. Due donazioni diverse possono avere gli stessi dati. Anche il controllo basato sull'ora non è affidabile: più donazioni diverse possono arrivare quasi contemporaneamente. Se manca l'identificatore, si può temporaneamente confrontare una combinazione di campi e orario, ma è una soluzione di riserva con il rischio di unire erroneamente due eventi.

La protezione dai duplicati deve trovarsi prima della visualizzazione dell'alert, non all'interno dell'animazione. Altrimenti la seconda chiamata aggiungerà comunque un elemento alla pagina, riprodurrà il suono o inserirà un'altra voce in coda. Controlla separatamente la coda: un singolo evento deve essere aggiunto una sola volta, e una chiamata ripetuta non deve avviare una seconda coda indipendente.

Se l'evento viene trasmesso tra più schede o componenti, verifica che non venga elaborato da più destinatari contemporaneamente. Un unico canale di messaggi condiviso può essere collegato a più gestori. In tal caso bisogna lasciare un solo consumatore oppure definire esplicitamente quale componente è responsabile della visualizzazione dell'alert.

Perché la pulizia della cache non sempre aiuta

Dopo l'aggiornamento della sorgente browser spesso si consiglia di svuotare la cache. Questo può risolvere la situazione se è stata caricata una vecchia versione dello script, ma la cache non rimuove i gestori superflui in una pagina già in esecuzione e non chiude la seconda copia della sorgente. Se il duplicato si ripete stabilmente dopo ogni riconnessione, la causa è quasi certamente nella logica di connessione o nella struttura della scena.

Verifica che venga effettivamente caricata la nuova versione dei file. Modifica temporaneamente l'indirizzo della risorsa o usa il meccanismo di aggiornamento previsto, poi riavvia la sorgente browser. Dopodiché ripeti il test con una sola finestra e una sola istanza della sorgente. Non aggiungere parametri casuali al link in modo permanente: potresti creare molte varianti in cache e rendere più difficile la diagnosi.

Se viene usata una cache intermedia o un service worker, anche questi possono servire uno script obsoleto. In tal caso confronta la versione del file caricato con quella che ti aspetti di vedere. Ma anche con un file vecchio occorre eliminare la causa della sottoscrizione ripetuta, altrimenti il problema ricomparirà dopo il prossimo aggiornamento.

Cosa controllare nel codice dell'alert

Per prima cosa individua tutti i punti in cui vengono chiamati socket.on, addEventListener, le funzioni di connessione e l'avvio della coda. A volte il problema non è in un singolo gestore, ma nel fatto che due moduli diversi ascoltano indipendentemente l'evento donation e ciascuno avvia la propria visualizzazione.

Poi controlla il ciclo di vita del componente, se l'alert viene mostrato tramite un framework. La sottoscrizione va inserita in un effetto o in un blocco equivalente, restituendo una funzione di pulizia. Non si deve creare un nuovo gestore a ogni aggiornamento dello stato senza rimuovere il precedente. In JavaScript normale è importante memorizzare il riferimento al socket attivo e al gestore corrente, così da poterli chiudere correttamente all'arresto della pagina.

Controlla i timer di riconnessione. Un nuovo timer non deve essere avviato sopra quello vecchio. Altrimenti dopo diverse interruzioni si creano tentativi di connessione paralleli e, con essi, sottoscrizioni aggiuntive. Per ogni timer serve una pulizia tramite clearTimeout o clearInterval, se non è più necessario.

Esamina separatamente il codice che mostra l'alert. Non deve aggiungere l'elemento alla coda e allo stesso tempo richiamare subito la funzione di visualizzazione per lo stesso oggetto. Verifica anche che l'animazione non venga riavviata quando cambia lo stato dell'elemento. Se nel log c'è una sola ricezione e una sola voce in coda, ma sullo schermo compaiono due notifiche, è proprio qui che devi cercare.

Checklist di diagnosi: cosa fare in ordine

1. Apri l'URL della sorgente browser in una scheda separata e invia una donazione di test. Annota se il duplicato compare fuori da OBS.
2. Lascia nella scena una sola istanza della sorgente. Controlla le copie delle scene, le scene annidate e i livelli in cui potrebbe trovarsi lo stesso indirizzo.
3. Aggiungi un log con l'identificatore dell'evento nelle fasi di ricezione, inserimento in coda e visualizzazione. Così sarà visibile dove aumenta il numero di oggetti.
4. Individua tutte le chiamate a socket.on e addEventListener. Verifica che i vecchi gestori vengano rimossi tramite socket.off e removeEventListener con lo stesso riferimento alla funzione.
5. Controlla la riconnessione: il vecchio socket viene chiuso, il vecchio timer viene annullato e non viene creata una nuova sottoscrizione sopra quella precedente?
6. Aggiungi il controllo dell'identificatore univoco della donazione prima della coda, poi riavvia completamente la sorgente e ripeti il test con un singolo evento.

Se la scheda separata riceve l'evento una sola volta ma OBS mostra due alert, cerca una seconda istanza della sorgente o una duplicazione nelle scene. Se l'evento arriva due volte già nella scheda separata, controlla le sottoscrizioni, le connessioni e la consegna lato server. Se ricezione e coda vengono registrate una sola volta ma sullo schermo compaiono due notifiche, il problema è nel livello visivo.