Открытые линии Битрикс24 не закрываются: сообщения из Wazzup приходят из 58520 года

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

Причина нашлась в логе: почти все входящие сообщения из WhatsApp приходили на портал с датой в 58520 году.

Что нашлось в логе

Для разбора взял imopenlines.log за пять суток: 57 МБ, около 30 тысяч событий. 96% трафика открытых линий на этом портале шло через Wazzup (WhatsApp).

Во входящих событиях CONNECTOR - ENTITY ADD у сообщения есть дата. В 7 111 случаях из 7 224 (98,4%) она выглядела так:

[date] => 58520-02-06 18:00:01.000000

Рядом в том же логе лежали нормальные даты: 1784705238 и 2026-07-20T06:45:25-06:00. Значит, портал умеет принимать время правильно, а ломает его один источник.

Откуда 58520 год

При тех настройках интеграции, что стояли на портале, Wazzup отдавал время сообщения в миллисекундах: 1784705238000, тринадцать цифр. Коннектор на стороне Битрикс24 читает это число как секунды. 1 784 705 238 000 секунд от 1970 года как раз дают 58 520 год.

Правильное значение в секундах, 1784705238, это 20 июля 2026. Ошибка в три нуля.

Почему это не косметика

Неверная дата в карточке сообщения выглядит как мелочь. На деле она выключает уборку.

Агенты открытых линий закрывают и чистят сессии по простому условию: последнее изменение было раньше, чем «сейчас минус таймаут». Сессия, у которой дата в 58520 году, под это условие не попадет никогда. Она остается открытой навсегда, и вместе с ней остается все, что к ней привязано:

• чат и его участники;
• счетчики непрочитанного у операторов;
• служебные записи сессии, индексы, статистика по ответам;
• место в списке недавних диалогов у каждого оператора: портал перебирает их при каждом открытии чатов.

Индексы по дате теряют смысл, когда в таблице есть записи «из будущего», и выборки по истории начинают читать больше, чем нужно. В том же логе 81 ошибка NO LAST SESSION: портал не может найти последнюю сессию клиента. Скорее всего, это тоже следствие битых дат.

Масштаб такой: открытые линии на этом портале создавали 83% всех сообщений, около 4 тысяч в сутки, полтора миллиона в год. Каждая сессия, которая не закрылась, оставляет след в базе навсегда.

Почему этого не видно при подключении

Интеграцию проверяют так: написали в WhatsApp, сообщение пришло в Битрикс24, оператор ответил, клиент получил ответ. Все работает, задачу закрывают.

Дату сообщения в этой проверке никто не смотрит. В интерфейсе она почти не видна, а последствия копятся в базе месяцами. Когда портал начинает тормозить, интеграцию уже давно считают рабочей, и искать начинают в другом месте: железо, кеш, «Битрикс тяжелый».

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

Что сделали

Чинили в три шага, и порядок тут важен. Потом поставили контроль на будущее.

Сначала остановили поток битых дат. Пока новые сообщения приходят из 58520 года, любая уборка бесполезна: через час появятся новые вечные сессии. Чинить стали там, где ошибка рождается, на стороне Wazzup: настроили отправку даты в том формате, который ждет Битрикс24. Код портала при этом не трогали, так что обновление Битрикс24 правку не откатит.

Проверить результат просто. В imopenlines.log у новых событий CONNECTOR - ENTITY ADD дата снова сегодняшняя, а число сообщений из будущего (первый запрос в конце статьи) перестает расти. После смены настройки дата начала приходить в нужном формате.

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

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

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

Напоследок поставили сторожа. Настройку интеграции могут случайно поменять, а Wazzup может обновить свою сторону, и тогда даты снова поедут. Узнавать об этом через полгода по тормозам портала не хочется, поэтому добавили простой контроль через списки Битрикс24. Каждое входящее сообщение создает элемент списка, записи живут один день. Если год в дате сообщения отличается от текущего, уведомление сразу уходит администратору Битрикс24 и директору IT-департамента. Теперь о такой аварии узнают сразу и успевают отреагировать до того, как база снова разрастется.

Попутно в том же логе нашлась вторая причина висящих сессий, уже не техническая. Сотрудники подхватывали чужие диалоги, но у их роли не было права «закрывать чужие диалоги». Попытка закрыть падала с ошибкой ERROR_USER_NOT_OPERATOR, 60–90 раз в сутки, и диалог оставался открытым. Это лечится одной галочкой в правах линии.

Как проверить у себя

Если на коробочном портале открытые линии работают через Wazzup или другой коннектор мессенджеров, эти запросы покажут, есть ли проблема:

-- сообщения и сессии с датой больше чем на год вперед
SELECT COUNT(*) FROM b_im_message          WHERE DATE_CREATE > NOW() + INTERVAL 1 YEAR;
SELECT COUNT(*) FROM b_imopenlines_session WHERE DATE_CREATE > NOW() + INTERVAL 1 YEAR;

-- сколько сессий сейчас открыто
SELECT COUNT(*) FROM b_imopenlines_session WHERE CLOSED = 'N';

Если MySQL работает не в строгом режиме, вместо даты из будущего может лежать 0000-00-00. Ищите и ее.

Если открытых сессий тысячи, а операторы ведут десятки диалогов, стоит посмотреть в imopenlines.log поле [message][date] в событиях CONNECTOR - ENTITY ADD. И заодно проверить в настройках линии, могут ли сотрудники закрывать диалоги, которые взяли у коллег.