Чому один донат викликає два алерти після оновлення браузерного джерела

Чому один донат викликає два алерти

Після оновлення браузерного джерела сторінка запускається заново. Скрипт знову підключається до сервера, підписується на події та створює обробники для показу повідомлень. Якщо старий обробник не видалено або одночасно працюють два підключення, одна подія донату обробляється кілька разів.

Саме оновлення не обов'язково є причиною збою. Воно часто лише виявляє помилку в логіці підключення. Наприклад, функція ініціалізації може запускатися під час завантаження сторінки, потім під час відновлення з'єднання і ще раз після отримання службового повідомлення. Кожен запуск додає нову підписку на подію 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 показує два алерти, шукайте другий екземпляр джерела або дублювання в сценах. Якщо подія приходить двічі вже в окремій вкладці, перевіряйте підписки, з'єднання та серверну доставку. Якщо отримання і черга фіксуються один раз, але на екрані два повідомлення, проблема знаходиться у візуальному шарі.