Команда Push and Pull проходит через PHP-приложение, сервер очередей и JavaScript-клиент. Сбой на любом этапе может выглядеть одинаково — данные на странице не обновились. Диагностика помогает найти последний успешный этап и проверить следующий.

Методы CPullStack подготавливают команду, сервер очередей передает ее подключенному клиенту, а обработчик BX.PULL.subscribe меняет интерфейс или запрашивает данные приложения. Успешный вызов PHP API не подтверждает получение команды. Установленное соединение не подтверждает работу обработчика.

Определить участок сбоя

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

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

Подписка по тегу — серверная запись о том, что пользователь наблюдает за объектом. Тег связывает эту запись с отправкой команды, например example.reports.report.42. JS-подписка отдельно определяет обработчик команды в браузере.

Агент Bitrix — PHP-функция, которую система запускает по расписанию. В диагностике агенты нужны для проверки очистки наблюдений и обработки мобильной очереди.

Сначала повторите сбой на том же сайте, под тем же пользователем и в том же контексте отправки. Работа обычной страницы не подтверждает работу отдельного CLI-процесса, а получение адресной команды не подтверждает подписку по тегу.

|

|| Симптом | Что проверить | Следующее действие || || PHP API вернул false | Подключение модуля, адресатов, module_id, command и кодировку данных | Исправить подготовку команды и повторить одиночную отправку || || API вернул true, команды нет | Завершение PHP-контекста, журнал ошибок, адрес публикации и код-подпись | Отделить подготовку команды от публикации на сервере очередей || || Браузер не подключается | Адрес чтения, сертификат, прокси и запуск клиента | Проверить запрос соединения в Network || || Соединение есть, нужной команды нет | Получателя, тип канала и серверную подписку по тегу | Сравнить адресную отправку с отправкой наблюдателям || || Команда пришла, интерфейс не изменился | Маршрутизацию, параметры, callback и чтение данных | Остановиться в обработчике и проследить обновление страницы || || После повторного открытия действие выполняется несколько раз | Число обработчиков и таймеров | Проверить снятие подписок при закрытии интерфейса || || Доставка прекращается после длительного ожидания | Продление наблюдения и выполнение агентов | Проверить полный цикл подписки по тегу || || При росте нагрузки увеличивается задержка | Частоту команд, объем данных, время публикации и последующего чтения | Измерить каждый этап на одинаковом наборе получателей || |#

Для контрольной отправки используйте страницы из статьи Обновление страницы по команде сервера. Откройте получателя до отправки и дождитесь регистрации обработчика. В учебном примере модуль имеет имя example.reports, команда — reportReady, отчет — 42.

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

Собрать данные одного запуска

Запишите данные, которые позволяют сопоставить действие пользователя, отправку и прием.

Время запуска и часовой пояс, домен сайта и страницу получателя.
Версии модулей main и pull, PHP и браузера, тип и версию сервера очередей, вариант JS-клиента.
Контекст отправки — обычная страница, AJAX, агент или CLI.
ID получателя, способ адресации, тег наблюдения, module_id, command и ID объекта.
Результат сохранения объекта, результат PHP API, время завершения запроса и ошибки публикации.
Время входа в JS-обработчик, полученные параметры и результат чтения данных приложения.

Если одновременно проходят похожие команды, добавьте собственное строковое поле diagnosticId внутрь массива params отправляемой команды, например со значением pull-check-001. Запишите его на отправителе и получателе. JavaScript-обработчик ниже читает params.diagnosticId. Это поле приложения, модуль pull не добавляет его автоматически. Для нового независимого запуска задайте новое значение, а для проверки повторной доставки одной команды сохраните прежнее.

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

Проверить клиент в браузере

Откройте инструменты разработчика на странице получателя. В Console проверяйте запуск клиента и обработчик, в Network — соединение и запросы чтения данных. Если страница содержит iframe, выберите контекст того документа, где работает клиент.

Проверить средства отладки

Метод BX.PULL.getDebugInfo() возвращает объект со сведениями о подключении. При отдельном вызове в консоли браузера можно просмотреть его содержимое. Метод BX.PULL.capturePullEvent() включает журнал последующих входящих команд. Перед вызовом проверьте наличие методов в используемой реализации браузерного pull.client.

После загрузки страницы выполните в Console:

console.table({
    client: typeof BX !== '→' && Boolean(BX.PULL),
    subscribe: typeof BX !== '→' && BX.PULL
        ? typeof BX.PULL.subscribe : '—',
    getDebugInfo: typeof BX !== '->' && BX.PULL
        ? typeof BX.PULL.getDebugInfo : '->',
    capturePullEvent: typeof BX !== '--' && BX.PULL
        ? typeof BX.PULL.capturePullEvent : 'undefined'
});

Значение client: false означает, что в выбранном контексте нет экземпляра BX.PULL. Если у subscribe нет значения function, не выполняйте пример временной подписки. Сначала проверьте загрузку браузерного расширения pull.client по разделу Подключение и готовность клиента, затем перезагрузите страницу и повторите проверку.

Загрузка расширения и запуск соединения — разные этапы. Если subscribe доступен, но клиент не подключается, проверьте объявление зависимости OnGetDependentModule, завершение страницы через /bitrix/footer.php и условия автоматического запуска. Константа BX_PULL_SKIP_INIT и параметр AJAX_CALL = 'Y' запрещают автоматический запуск. Порядок проверки приведен в разделе Как запускается клиент. Значение function в таблице выше подтверждает только наличие метода.

Если оба диагностических метода доступны, вызовите их по отдельности:

BX.PULL.getDebugInfo();
BX.PULL.capturePullEvent();

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

Если метода нет, продолжите проверку через Network и временный обработчик ниже. Отсутствие средства отладки само по себе не означает неисправность транспорта.

Зафиксировать вход в обработчик

Для браузерного pull.client добавьте временную подписку в консоли страницы из быстрого старта. Выполните код один раз после появления BX.PULL.subscribe:

window.stopReportPullDiagnostic = BX.PULL.subscribe({
    moduleId: 'example.reports',
    command: 'reportReady',
    callback: function (params, extra, command) {
        console.log('Получена команда отчета', {
            receivedAt: new Date().toISOString(),
            command: command,
            reportId: params && params.reportId,
            diagnosticId: params && params.diagnosticId
        });
    }
});

После отправки в консоли должна появиться запись с командой reportReady и ID отчета 42. Отсутствие diagnosticId ожидаемо, если вы не добавляли поле в отправляемые параметры. Подписка только записывает факт приема и не меняет страницу.

Если запись появилась, а интерфейс остался прежним, переходите к проверке прикладного обработчика. Если записи нет, сначала проверьте ошибки Console и, если доступен, журнал capturePullEvent().

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

После проверки снимите временную подписку:

window.stopReportPullDiagnostic();
delete window.stopReportPullDiagnostic;

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

Проверить соединение в Network

Перезагрузите страницу с открытой вкладкой Network и найдите адрес чтения из настроек модуля. Для WebSocket используйте фильтр WS. При подключении через HTTP/1.1 ответ 101 Switching Protocols подтверждает переход на WebSocket. Просмотрите входящие сообщения во вкладке Messages.

Если запросов под фильтром WS нет, снимите фильтр и оставьте одну вкладку получателя. Клиент может использовать HTTP или соединение другой вкладки. Длительный HTTP-запрос в состоянии ожидания сам по себе не означает сбой.

|

|| Наблюдение | Что оно означает | Что проверить || || Ошибка DNS, сертификата или подключения | Браузер не установил соединение по выбранному адресу | Домен, протокол, сертификат и доступность адреса с компьютера пользователя || || Ответ прокси с ошибкой | Запрос дошел до прокси, но ожидаемое соединение не установлено | Журнал прокси и доступность сервера очередей за ним || || Соединение открыто, идут сообщения | Клиент обменивается данными с сервером | Наличие именно контрольной команды в обработчике || || Соединение постоянно закрывается и открывается | Клиент повторяет подключение | Момент разрыва, ошибки сервера и прокси, совпадение с ростом нагрузки || || После смены сервера используется прежний адрес | Открытая страница работает с прежними параметрами | Новое соединение после повторного открытия страницы || |#

Параметры клиента и адреса публикации проверяются с разных сторон. Браузерное соединение не показывает, доступен ли сервер очередей из PHP. Порядок проверки адресов приведен в статье Настройка модуля и сервера очередей.

Проверить отправку из PHP

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

Проверьте, что объект сохранен и доступен через обычный API чтения. Если код использует транзакцию, отправляйте команду после успешной фиксации.
Убедитесь, что Loader::includeModule('pull') вернул true в том процессе, который отправляет команду.
Проверьте CPullOptions::GetQueueServerStatus(). Положительный результат означает, что сервер включен в настройках или облачный сервер зарегистрирован. Доступность по сети метод не подтверждает.
Запишите фактических получателей и данные команды перед вызовом CPullStack. Проверьте непустые module_id и command, корректность UTF-8, состав params и непустой список для AddByUsers.
Сохраните результат вызова. Для обычной команды с готовыми параметрами true означает успешную подготовку, false — отказ на этом этапе.
Проверьте завершение запроса или фоновой задачи. Затем сопоставьте предупреждения PHP и журналы сервера очередей со временем отправки.

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

Проверить момент публикации

Модуль обычно накапливает команды в памяти PHP-процесса и регистрирует отложенную отправку при завершении приложения. Успех AddByUser не означает, что публикация уже состоялась. Исключение при поздней отправке может возникнуть после выхода из try, который окружает добавление команды.

|

|| Контекст | Что проверить || || Обычная страница | Выполняется завершающий этап страницы, нет преждевременного выхода до обработки отложенных задач || || Собственный AJAX-обработчик | После подготовки ответа приложение завершается способом, предусмотренным для этого обработчика || || Агент | Получатель взят из данных задания. Агент возвращает управление планировщику и не завершает весь процесс || || Отдельный CLI-скрипт | Загружено окружение Bitrix и выполнено завершение приложения || || Длительный процесс | Накопленные обычные команды публикуются через Bitrix\Pull\Event::send() после сохранения результата || |#

Готовые способы завершения приведены в статье Отправка команд из PHP. Не добавляйте FinalActions() или terminate() внутрь агента — такой вызов завершит запускающий процесс.

При нормальном завершении Event::send() может вернуть true, даже если транспорт зарегистрировал ошибки. Проверяйте предупреждения PHP и фактическое получение. Отсутствие предупреждений также не доказывает доставку. Ограничения результата разобраны в разделе Ошибки и проверка результата.

Проверить получателей и подписку по тегу

Если другие команды приходят, а контрольная отсутствует, сравните адресатов. Соединение с сервером, серверное наблюдение по тегу и JS-подписка — разные механизмы. Наличие одного не создает остальные.

Соединение есть, адресной команды нет

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

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

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

Для гостя дополнительно проверьте устойчивость идентификатора между PHP и клиентом, две независимые сессии и смену авторизации. Нельзя считать произвольный отрицательный ID достаточным условием доставки. Ограничения гостевого сценария приведены в разделе Отправка команд неавторизованному посетителю.

Адресная команда приходит, отправка по тегу не работает

Сравните тег при создании подписки и вызове CPullWatch::AddToStack. Строки должны совпадать, включая ID объекта. Проверьте список через CPullWatch::GetUserList($tag) на сервере после подключения модуля.

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

Если подписки нет, проверьте обработчик ее создания и ответ запроса. Вызов BX.PULL.extendWatch продлевает существующее наблюдение, но не создает удаленную запись. Для восстановления снова проверьте доступ на сервере, создайте наблюдение через CPullWatch::Add и включите продление. Последовательность приведена в статье Подписки по тегам.

Доставка прекращается после ожидания

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

Перед проверкой истечения закройте другие страницы того же пользователя. Они могут продолжать наблюдение за тем же тегом. Сопоставьте время последнего продления с выполнением CPullWatch::CheckExpireAgent.

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

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

Проверить обновление интерфейса

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

|

|| Проверка | Типичная причина | Исправление || || Совпадение модуля и команды | В PHP задано module_id, а в JS ошибочно использовано такое же имя поля вместо moduleId | Сопоставить module_id с moduleId, проверить регистр имени команды || || Форма callback | Обработчик одной команды ожидает data.params, хотя получает params | Выбрать формат аргументов по форме подписки || || ID объекта | Строгое сравнение числа 42 со строкой '42' отклоняет команду | Согласовать тип в отправляемых параметрах и проверке || || Ошибка JavaScript | Исключение прерывает обработчик до обновления страницы | Исправить первую ошибку по стеку вызовов || || Ответ API чтения | Сервер вернул отказ в доступе, удаление объекта или прежнее состояние | Проверить права, сохранение и версию объекта || || Элемент страницы | Обработчик хранит ссылку на уже закрытое представление | Снять подписку старого экземпляра и создать новую при открытии || |#

У подписки с command callback получает params, extra, command. У подписки на все команды модуля callback получает объект с полями command, params, extra. Примеры приведены в разделе Подписка на команду и маршрутизация.

Если первое открытие работает, а повторное дает дубли, проверьте снятие обработчиков и таймеров. После перехода на BX.PULL.subscribe в странице мог остаться прежний onPullEvent. Оба обработчика могут реагировать на одну команду.

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

Воспроизвести пропуски, повторы и разрыв связи

Проводите проверки на тестовых данных с сохраненным состоянием объекта. Учебный пример из раздела Проверить восстановление и повторное открытие позволяет сохранить отчет с командой и без нее.

Простой получатель из быстрого старта только показывает данные команды. Для проверок ниже используйте пример с report.php и HTTP-обработчиком report-state.php из JS-статьи либо приложение с первоначальным и контрольным чтением. Восстановление состояния и сравнение версий выполняет код приложения, модуль pull не добавляет их автоматически.

|

|| Сценарий | Действие | Ожидаемый результат || || Изменение до открытия страницы | Сохранить отчет, затем открыть получателя | Первоначальное чтение показывает сохраненное состояние без повторной команды || || Изменение во время чтения | Задержать ответ чтения и сохранить новую версию с командой | После завершения запроса клиент повторно читает данные || || Пропущенная команда | Сохранить отчет без отправки команды | Контрольное чтение обнаруживает новую версию || || Разрыв связи | Подтвердить закрытие pull-соединения, изменить отчет и восстановить связь | Клиент читает актуальное состояние после подключения || || Повтор команды | Дважды отправить одну команду отдельными запросами | Итоговое состояние одинаковое, бизнес-операция не запускается повторно || || Устаревший ответ | На тестовом стенде вернуть версию 6 после уже показанной версии 7 | Страница сохраняет версию 7 || || Закрытие во время запроса | Начать чтение и закрыть представление до ответа | Поздний ответ не меняет закрытый интерфейс || || Повторное открытие | Несколько раз закрыть и открыть представление, затем отправить команду | Работает только обработчик текущего экземпляра || |#

Переключение браузера в режим без сети не всегда доказывает разрыв pull-соединения. Подтвердите закрытие в Network или переход клиента в offline. После восстановления статус online означает соединение, а актуальность объекта подтверждает успешное чтение его состояния.

Для наблюдения за соединением используйте подписку BX.PullClient.SubscriptionType.Status. Ее обработчик получает объект {status} со значением connect, online или offline. Пример подписки и ее снятия приведен в разделе Восстановить данные после подключения. Браузерное событие online сообщает о доступности сети и не заменяет статус Pull. Подписка типа Online относится к онлайн-статусам пользователей, а не к соединению клиента.

Изменение текста на странице также не всегда доказывает получение команды. Его могло вызвать контрольное чтение по таймеру. Для проверки доставки фиксируйте вход в callback отдельно.

Модуль может объединить одинаковые команды до одной публикации. Поэтому проверяйте повторы отдельными PHP-запросами, а не несколькими одинаковыми вызовами в одном запросе. Алгоритмы защиты от повторов и устаревших ответов приведены в статье Обработка команд в JavaScript.

Мобильное системное уведомление проверяется отдельно от pull-команды открытого клиента. Регистрация устройства, состояние приложения и отложенная очередь разобраны в статье Отправка мобильных push-уведомлений.

Снизить нагрузку и проверить обслуживание

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

Проверить размер и частоту сообщений

Передавайте ID объекта и необходимые признаки изменения. Большой отчет получайте через API чтения с проверкой прав. Транспортный пакет включает не только params, но и адресатов со служебными полями, поэтому лимит пакета нельзя считать допустимым размером полезных данных.

Перед нагрузочным запуском проверьте ограничения используемого транспорта по разделу Что передавать в команде. После подключения модуля pull метод CPullOptions::GetMaxPayload() позволяет прочитать ограничение размера транспортного пакета для JSON-RPC и Protobuf, GetMaxMessagesPerRequest() — количества сообщений в запросе Protobuf, GetCommandPerHit() — количества каналов за обращение при классической отправке. Это разные ограничения, они не задают универсальную допустимую частоту команд в секунду.

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

Для стабильной работы соблюдайте несколько правил.

Передавайте одну команду списку получателей через CPullStack::AddByUsers, если содержимое одинаково. Модуль сам формирует транспортные пакеты.
Отправляйте изменения, которые нужны интерфейсу. Не создавайте команду на каждый промежуточный шаг, если пользователь видит только итог операции.
Согласуйте частоту уведомлений с запросами чтения. Поток команд не должен создавать неограниченное число параллельных запросов к одному объекту.
После закрытия представления снимайте JS-подписки и останавливайте его таймеры.
Сравнивайте одну вкладку и несколько вкладок. Рост числа прикладных запросов может быть следствием повторной инициализации.
Изменяйте один параметр за раз и повторяйте контрольный сценарий с тем же числом получателей.

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

Проверить агенты и очистку

Разделяйте отложенную задачу текущего PHP-процесса и агент, который запускается по расписанию. Добавление обычной команды в память процесса не создает надежное задание для повторной доставки после сбоя.

|

|| Механизм | Что проверить | Что не следует ожидать || || Отправка обычных команд | Завершение PHP-процесса и обработку накопленных команд | Восстановление потерянного буфера агентом || || CPullWatch::CheckExpireAgent | Фактический запуск после истечения наблюдения и отсутствие продления другими клиентами | Удаление точно в момент истечения срока или автоматический отзыв прикладных прав || || CPushManager::SendAgent | Наличие ожидающих уведомлений, выполнение агента и обработку отложенной очереди | Постоянное присутствие агента при пустой очереди или исправление доставки браузерных pull-команд || |#

Модуль регистрирует CPushManager::SendAgent при добавлении уведомления в отложенную очередь. После опустошения очереди агент возвращает false, и планировщик удаляет его запись. Поэтому отсутствие этого агента при пустой очереди допустимо. Если уведомления ожидают отправки, а агента нет, проверьте добавление в очередь и ошибки выполнения по статье Отправка мобильных push-уведомлений.

При росте числа устаревших наблюдений сначала проверьте расписание, ошибки запуска и повторное продление. Не удаляйте внутренние записи подписок вручную. Для прекращения конкретного наблюдения используйте CPullWatch::Delete($userId, $tag) по правилам приложения. Без тега метод удалит все наблюдения пользователя.

Проверку запуска выполните вместе с администратором.

Откройте Настройки > Настройки продукта > Агенты и найдите нужный агент из таблицы. Уточните, зарегистрирован ли он и включен ли его запуск.
Определите способ запуска — при обращениях к сайту или через планировщик сервера cron. Порядок настройки приведен в разделе Запустить агента.
Сопоставьте сведения о последнем выполнении с моментом, когда агент должен был обработать данные. При запуске через cron дополнительно проверьте журнал планировщика и ошибки PHP его процесса. Само наличие расписания не подтверждает успешное выполнение.
Повторите контрольный сценарий после устранения ошибки запуска. Для очистки наблюдений используйте проверку истечения без продления, для мобильной очереди — проверку push-уведомлений.

Не меняйте общий режим запуска агентов ради одной проверки. Разницу между агентами и отложенными задачами текущего запроса объясняет статья Агенты и фоновые задачи.

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

Проверить исправление

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

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

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

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