Чей кэш используют фоновые задания 1С и почему после динамического обновления выполняется старый код

Разберем распространенную ситуацию при разработке и сопровождении конфигураций 1С: разработчик вносит изменения в модуль, выполняет динамическое обновление информационной базы, не перезапуская свой пользовательский сеанс, и запускает фоновое задание. К удивлению разработчика, алгоритм продолжает отрабатывать по старому сценарию, словно изменения не вносились.

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

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

Рассмотрим, что происходит во время вызова фонового задания из клиентского приложения. Когда открытый сеанс пользователя инициирует фоновый процесс (например, через объект ФоновыеЗадания), платформа не просто берет свежий код с сервера СУБД или из текущей основной конфигурации. Она привязывает контекст выполнения создаваемого фонового задания к конкретному номеру версии метаданных родительского сеанса.

Проанализируем ключевые особенности этого механизма:

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

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

Различие между фоновыми и регламентными заданиями

Разберем разницу в поведении процессов при динамическом обновлении конфигурации:

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

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

Способы решения и практические рекомендации

Проанализируем основные варианты действий, если необходимо применить изменения в коде фоновых заданий:

1. Перезапуск клиентского сеанса. Самый простой и надежный способ — завершить работу пользовательского сеанса и войти в систему заново. Новый сеанс получит от сервера актуальный номер версии конфигурации.
2. Принудительное завершение устаревших сеансов. В административной практике рекомендуется завершать активные сеансы пользователей через консоль кластера серверов 1С или утилиту администрирования после проведения динамического обновления.
3. Отказ от динамического обновления для критичной бизнес-логики. Если логика фоновых процессов часто меняется, рекомендуется выносить её во внешние обработки или сервисы, либо использовать плановые технологические окна с полной перезагрузкой сеансов.

Посмотрим на пример вызова фонового задания из кода программы:

ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(Параметр1);

// Фоновое задание унаследует версию метаданных текущего сеанса
ФоновоеЗадание = ФоновыеЗадания.Выполнить("НаименованиеМодуля.ИмяПроцедуры", ПараметрыЗадания);

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