imconnector 26.200.200 Заметное

Imconnector 26.200.200: закрытие сессии открытой линии больше не обгоняет открытие

3 мин чтения
Узнавайте о ломающих изменениях Битрикса раньше, чем они доедут до прода: свежие разборы — в канале @bxmax_updates

В imconnector 26.200.200 закрытие сессии открытой линии больше не доходит до imbot раньше повторного открытия, поставленного перед ним в том же запросе, а коннектор MAX стал доступен порталам с регионами az, am и md. В коробочный Битрикс24 версия вышла 2 сентября 2026 года, так указано в официальном канале «Битрикс24 changelog». Сигнатуры существующих методов и БД не менялись, но причина бага сидит в очереди фоновых задач main и касается любого кода, где несколько задач addBackgroundJob() с одним приоритетом должны выполниться по порядку.

Одна фоновая задача на все события сессий

Правка сделана в protected Bitrix\ImConnector\Provider\Network\Output::addEventSession(), его вызывают sessionStart() и sessionFinish(). До 26.200.200 каждое событие ставило свою фоновую задачу \Bitrix\ImBot\Service\Openlines::sessionStart или sessionFinish с JOB_PRIORITY_LOW. Теперь события копятся в статическом буфере Output::$sessionEvents. Приватный queueSessionEvent() на первом событии регистрирует одну задачу [Output::class, 'sendSessionEvents'], и она отправляет события в том порядке, в каком они возникли.

Срочные события ($immediately = true) по-прежнему уходят сразу, но перед ними вызывается self::sendSessionEvents(), чтобы срочное событие не обогнало уже накопленные. Срочная отправка очищает буфер, а уже поставленная задача остаётся в очереди, и следующее отложенное событие того же запроса регистрирует ещё одну задачу. Буфер у задач общий, поэтому первая отправит всё, остальные ничего не сделают, и порядок сохранится. Этот случай разобран в docblock queueSessionEvent().

Ищите сбои imbot в логе

Внутри sendSessionEvents() каждое событие обёрнуто в try/catch (\Throwable). Ошибка пишется через Application::getInstance()->getExceptionHandler()->writeToLog(), и остальные события цепочки всё равно уходят. Application::runBackgroundJobs() в main после всех задач повторно выбрасывает последнее пойманное исключение, но из sendSessionEvents() исключение наружу больше не выходит. Сбои Openlines::sessionStart() и sessionFinish() для накопленных событий теперь видны только в логе обработчика исключений.

Не рассчитывайте на порядок addBackgroundJob()

Причину бага объясняет docblock queueSessionEvent(). SplPriorityQueue не упорядочивает задачи с одинаковым приоритетом, поэтому при отдельных задачах закрытие сессии могло уйти раньше повторного открытия из того же запроса. Очередь фоновых задач ядра построена на том же классе. В bitrix/modules/main/lib/Application.php она создаётся строкой $this->backgroundJobs = new \SplPriorityQueue(). Значит, и в вашем коде две задачи addBackgroundJob() с одним приоритетом не обязаны выполниться в порядке добавления.

Если порядок важен, ставьте одну задачу и задавайте последовательность внутри неё:

        <?php declare(strict_types=1);

namespace Vendor\Crm\Sync;

use Bitrix\Main\Application;

final class DealCloser
{
    public function __construct(
        private readonly DealGateway $gateway,
    ) {}

    public function closeLater(int $dealId): void
    {
        // Так порядок не гарантирован, приоритет у задач одинаковый:
        // addBackgroundJob([$this->gateway, 'close'], [$dealId]);
        // addBackgroundJob([$this->gateway, 'notifyManager'], [$dealId]);

        Application::getInstance()->addBackgroundJob(function () use ($dealId): void {
            $this->gateway->close($dealId);
            $this->gateway->notifyManager($dealId);
        });
    }
}

    

Если события возникают в разных местах запроса и одной задачей их не собрать, повторите приём imconnector. Копите события в буфер, задачу регистрируйте на первом из них, а внутри обходите буфер по порядку и ловите исключения на каждом шаге, чтобы одна ошибка не обрывала цепочку. Буфер нужен один на запрос, так что держите его в статическом свойстве или в сервисе из ServiceLocator. Заодно поищите в /local/ вызовы addBackgroundJob(), которые идут подряд с одним приоритетом и зависят друг от друга.

MAX открыт для az, am и md

В Bitrix\ImConnector\Library::CONNECTOR_PER_REGION_LIMITATION[ID_MAX_CONNECTOR]['allow'] добавили az, am и md. Было ru, by, kz, kg, tj, uz, стало ru, by, az, am, kz, kg, md, tj, uz. Этот список проверяет Connector::isAllowedConnectorInRegion().

Мелочи

Новый публичный статический Output::sendSessionEvents(): void помечен @internal. Публичным его сделали, потому что он служит колбэком фоновой задачи, так что из своего кода его не зовите. Ещё output.php лишился бита исполнения (100755 → 100644), а в конец output.php и install/version.php дописали перевод строки. Deprecated в релизе нет.

Новая версия вышла — разбор уже в Telegram

В канале @bxmax_updates публикуем каждый свежий разбор: что сломается, что устарело и что появилось в API. Узнаете до того, как обновите прод.

Подписаться

Читайте дальше

timeman 26.350.0 Заметное Свежее

Timeman 26.350.0: план дня пишется в нужную запись, блоки БП возвращают Saved

В timeman 26.350.0 для коробочного Битрикс24 блоки «Сохранить план на день» и «Сохранить отчёт сотрудника за день» из нового конструктора бизнес-процессов научились писать в заданную запись рабочего дня, оставлять Markdown как есть и сообщать, сохранилось ли (у отчёта новые настройки в конструкторе,…

2 мин
rpa 26.300.0 Безопасность Свежее

Rpa 26.300.0: права на перемещение элементов наконец проверяются

До RPA 26.300.0 `UserPermissions::canMoveItem()` сразу отвечал `true`, и любой сотрудник, кроме экстранет-пользователей, мог перетащить любой элемент на любую стадию, а права стадии на перемещение не учитывались. Теперь права проверяются, а тем, кто может только смотреть, `rpa.item.get` и `rpa.item….

3 мин
booking 26.500.100 Заметное Свежее

Booking 26.500.100: addList отвечает ошибкой, когда не создал ни одной брони, а четыре колонки дат стали DATETIME

В коробочный Битрикс24 пришёл booking 26.500.100 с двумя правками. AJAX-экшен `booking.api_v1.Booking.addList` теперь возвращает ошибку, если не создал ни одной брони. Апдейтер переводит четыре колонки дат с `TIMESTAMP` на `DATETIME`, и в `install/migrations/tables.php` они объявлены через `datetime…

3 мин
socialnetwork 26.200.0 Безопасность Свежее

Socialnetwork 26.200.0: XSS в заявках и списке участников, копирование проекта по праву редактирования и курсор в log.blogpost.get

Socialnetwork 26.200.0 закрывает XSS в списке участников проекта и в заявках в группы, подмену ссылок через название группы и утечку задач в контекст AI. Копировать проект теперь можно только с правом на редактирование. Администраторам, у которых стояли 26.100.0 или 26.150.0, стоит проверить права с…

2 мин
Мы используем файлы cookie для улучшения работы сайта. Продолжая использовать сайт, вы соглашаетесь с нашей политикой конфиденциальности.
AI Домовой

AI Домовой История

на связи

пишет…
Нет истории чатов
AI Домовой

Нужна авторизация

Войдите, чтобы задавать вопросы AI Домовому.

Войти