Почему один донат вызывает два алерта после обновления браузерного источника

Почему один донат вызывает два алерта

После обновления браузерного источника страница запускается заново. Скрипт снова подключается к серверу, подписывается на события и создаёт обработчики для показа уведомлений. Если старый обработчик не удалён или одновременно работают два подключения, одно событие доната обрабатывается несколько раз.

Само обновление не обязательно является причиной сбоя. Оно часто только проявляет ошибку в логике подключения. Например, функция инициализации может запускаться при загрузке страницы, затем при восстановлении соединения и ещё раз после получения служебного сообщения. Каждый запуск добавляет новую подписку на событие donation.

В результате сервер отправляет один объект доната, но браузер вызывает одну и ту же функцию дважды. Иногда дублирование происходит на стороне сервера: приложение считает новое подключение отдельным получателем и отправляет событие и старой, и новой сессии. Поэтому сначала нужно определить, где появляется повтор: в источнике, в обработчике или на этапе отображения.

Как найти место, где возникает дубль

Начните с простого теста. Откройте ссылку браузерного источника в отдельном окне или вкладке, оставьте только один экземпляр страницы и отправьте тестовое событие. Если алерт появляется один раз, причина, скорее всего, связана с настройками сцены или с несколькими экземплярами источника. Если он дублируется уже в отдельной вкладке, проверяйте код страницы и механизм подписки.

Полезно разделить обработку доната на несколько этапов: получение события, проверка события, постановка алерта в очередь и отрисовка. В журнале или консоли временно выводите отметку на каждом этапе. Если запись о получении появляется дважды, проблема находится до визуального слоя. Если событие получено один раз, но в очереди два элемента, ошибка в обработчике. Если очередь содержит один элемент, а на экране два алерта, проверяйте функцию отображения и HTML-контейнер.

Для диагностики добавьте к каждому событию его идентификатор, если он передаётся в данных доната. Записывайте этот идентификатор при получении и перед показом. Одинаковый идентификатор в двух вызовах показывает, что одно событие обработано повторно. Два разных идентификатора говорят о двух доставках, которые нужно разбирать отдельно.

Проверяйте не только количество вкладок. В OBS два экземпляра могут появиться после копирования сцены, добавления вложенной сцены или повторного добавления браузерного источника с тем же адресом. Иногда один источник остаётся в отдельном слое, а второй добавляется поверх него. Визуально это выглядит как двойной алерт, хотя событие пришло один раз.

Повторная подписка после переподключения

Самая частая причина — обработчик добавляется при каждом подключении, но не снимается при отключении. Упрощённо проблема выглядит так: функция запускает socket.on с обработчиком показа алерта, затем соединение обрывается, приложение подключается снова и повторяет socket.on. После этого один входящий донат вызывает две функции. При следующем переподключении их может стать ещё больше.

Та же ошибка встречается с обычным addEventListener. Если функция инициализации вызывается несколько раз, браузер добавляет несколько слушателей одного события. Проверка флага «инициализация уже выполнена» помогает не всегда: при полноценном обновлении страницы переменные сбрасываются, а при переподключении внутри той же страницы проблема сохраняется.

Подписку нужно создавать один раз на жизненный цикл подключения, а старую подписку — явно удалять перед новой. Для обработчиков событий используется removeEventListener и та же ссылка на функцию, которая передавалась при подключении. Для библиотек с сокетами обычно нужен метод off, unsubscribe или аналогичный способ отключения.

Минимальная схема для сокета может выглядеть так: 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);

Здесь важна не конкретная библиотека, а порядок действий. Обработчик хранится в переменной, поэтому его можно снять той же ссылкой. Перед новой подпиской старая удаляется, а при закрытии страницы или остановке источника выполняется cleanup. Если при каждом запуске создаётся новый сокет, сначала нужно закрыть старый и только затем создавать новый. Иначе оба соединения могут продолжать получать одни и те же данные.

При переподключении также закрывайте старое соединение и очищайте связанные таймеры. Иначе старый сокет может продолжать получать данные, пока новый уже работает. Особенно часто это происходит, если код запускает новый таймер повторного соединения, не отменяя предыдущий.

Что проверить в OBS и браузерном источнике

Если отдельное окно показывает алерт один раз, переходите к сцене. Остановите предварительный просмотр, временно удалите лишние слои и оставьте один браузерный источник. Затем проверьте поведение на нужной сцене. Такой тест быстрее, чем одновременная проверка всех сцен и фильтров.

• Ищите два источника с одним и тем же адресом страницы.
• Проверяйте копии сцен и вложенные сцены, где может находиться тот же оверлей.
• Убедитесь, что алерт не выводится одновременно браузерным источником и другим слоем с той же страницей.
• После изменения настроек полностью перезапустите источник, а не только переключите сцену.

Иногда в OBS остаётся старая вкладка браузерного источника после обновления URL или параметров. Закрытие и повторное добавление источника помогает проверить гипотезу, но это не заменяет исправление кода. Если после каждого обновления проблема возвращается, ищите повторную регистрацию обработчика или двойное подключение.

Также учитывайте задержку отключения. При обновлении старая сессия может закрыться не мгновенно. Если сервер несколько секунд считает её активной, событие, пришедшее в этот промежуток, способно попасть в две сессии. Нормальная логика сервера должна удалять неактивные подключения и не оставлять подписку после закрытия страницы.

Защита от повторной доставки одного события

Даже при правильной работе браузерного источника одно событие иногда может быть доставлено повторно. Такое возможно при восстановлении соединения, повторной отправке сообщения или сбое между получением события и подтверждением его обработки. Поэтому обработчик алерта должен быть устойчивым к повторам.

Лучший способ — проверять уникальный идентификатор доната. Перед постановкой события в очередь сохраните его идентификатор в набор уже обработанных событий. Если такой идентификатор уже встречался, повтор нужно пропустить. Хранить список следует ограниченное время, чтобы он не рос бесконечно.

Не используйте для этого только сумму, имя отправителя или текст сообщения. Два разных доната могут иметь одинаковые данные. Проверка по времени тоже ненадёжна: несколько разных донатов могут прийти почти одновременно. Если идентификатора нет, можно временно сравнивать комбинацию полей и времени, но это запасной вариант с риском ошибочно объединить два события.

Защита от дублей должна находиться до показа алерта, а не внутри анимации. Иначе второй вызов всё равно добавит элемент на страницу, воспроизведёт звук или поставит ещё одну запись в очередь. Отдельно контролируйте очередь: одно событие должно добавляться в неё один раз, а повторный вызов не должен запускать вторую независимую очередь.

Если событие передаётся между несколькими вкладками или компонентами, проверяйте, не обрабатывают ли его сразу несколько получателей. Один общий канал сообщений может быть подключён к нескольким обработчикам. В таком случае нужно либо оставить одного потребителя, либо явно определить, какой компонент отвечает за показ алерта.

Почему очистка кэша помогает не всегда

После обновления браузерного источника часто советуют очистить кэш. Это может исправить ситуацию, если загрузилась старая версия скрипта, но кэш не удаляет лишние обработчики в уже работающей странице и не закрывает вторую копию источника. Если дубль стабильно повторяется после каждого переподключения, причина почти наверняка находится в логике соединения или в структуре сцены.

Проверьте, действительно ли загружается новая версия файлов. Временно измените адрес ресурса или используйте предусмотренный механизм обновления, затем перезапустите браузерный источник. После этого снова выполните тест с одним окном и одним экземпляром источника. Не добавляйте случайные параметры к ссылке постоянно: это может создать множество вариантов кэша и усложнить диагностику.

Если используется промежуточный кэш или service worker, он тоже может отдавать устаревший скрипт. В таком случае сравните версию загруженного файла и версию, которую вы ожидаете увидеть. Но даже при старом файле нужно устранить причину повторной подписки, иначе проблема появится снова после следующего обновления.

Что проверить в коде алерта

Сначала найдите все места, где вызываются socket.on, addEventListener, функции подключения и запуск очереди. Иногда проблема не в одном обработчике, а в том, что два разных модуля независимо слушают событие donation и каждый запускает свой показ.

Затем проверьте жизненный цикл компонента, если алерт выводится через фреймворк. Подписку размещают в эффекте или аналогичном блоке и возвращают функцию очистки. Нельзя создавать новый обработчик при каждом обновлении состояния без удаления предыдущего. В обычном JavaScript важно хранить ссылку на активный сокет и текущий обработчик, чтобы при остановке страницы их можно было корректно закрыть.

Проверьте таймеры повторного подключения. Новый таймер не должен запускаться поверх старого. Иначе после нескольких обрывов создаются параллельные попытки соединения, а вместе с ними — дополнительные подписки. Для каждого таймера нужна очистка через clearTimeout или clearInterval, если он больше не нужен.

Отдельно посмотрите на код, который показывает алерт. Он не должен одновременно добавлять элемент в очередь и сразу вызывать функцию отображения для того же объекта. Также проверьте, не запускается ли анимация повторно при изменении состояния элемента. Если в журнале одно получение и одна запись в очереди, а на экране два уведомления, искать нужно именно здесь.

Чек-лист диагностики: что делать по порядку

1. Откройте URL браузерного источника в отдельной вкладке и отправьте один тестовый донат. Зафиксируйте, появляется ли дубль вне OBS.
2. Оставьте в сцене только один экземпляр источника. Проверьте копии сцен, вложенные сцены и слои, где может находиться тот же адрес.
3. Добавьте журнал с идентификатором события на этапах получения, постановки в очередь и показа. Так будет видно, где количество объектов увеличивается.
4. Найдите все вызовы socket.on и addEventListener. Проверьте, снимаются ли старые обработчики через socket.off и removeEventListener с той же ссылкой на функцию.
5. Проверьте переподключение: закрывается ли старый сокет, отменяется ли старый таймер и не создаётся ли новая подписка поверх прежней.
6. Добавьте проверку уникального идентификатора доната перед очередью, затем полностью перезапустите источник и повторите тест с одним событием.

Если отдельная вкладка получает событие один раз, а OBS показывает два алерта, ищите второй экземпляр источника или дублирование в сценах. Если событие приходит дважды уже в отдельной вкладке, проверяйте подписки, соединения и серверную доставку. Если получение и очередь фиксируются один раз, но на экране два уведомления, проблема находится в визуальном слое.