В процессе разработки на платформе 1С:Предприятие, особенно при работе с Расширениями конфигурации и Хранилищем конфигурации, администраторы и разработчики могут столкнуться с фатальной ошибкой: недопустимое состояние объекта "jenkins backend". Данная ошибка возникает на этапе Реструктуризация таблиц информационной базы и делает обновление конфигурации невозможным. Рассмотрим способы диагностики и возможные пути обхода данной проблемы.
Важно понимать, что термин jenkins backend в сообщении об ошибке не означает наличие стороннего программного обеспечения типа Jenkins на вашем сервере. Это индикатор того, что ядро платформы 1С столкнулось с критическим рассогласованием в метаданных расширения во время транзакции к базе данных. Платформа не может корректно завершить слияние структур данных, что приводит к аварийному завершению процесса.
Если вы столкнулись с подобной ситуацией, рекомендуем действовать последовательно, начиная с наименее инвазивных методов.
Один из самых эффективных способов, который часто помогает «сбросить» состояние блокировки метаданных — это временное отключение расширения. Выполните следующие действия:
Расширение в списке расширений конфигурации.Иногда ошибка вызывается конфликтом версий платформы или устаревшими параметрами Режим совместимости. Если база долгое время находилась в разработке, попробуйте следующее:
Рассмотрите возможность временного понижения версии Режим совместимости конфигурации на один шаг назад. Это может привести к тому, что платформа пересоберет внутренние структуры метаданных, избегая конфликта при реструктуризации объектов, добавленных через Хранилище.
Хотя этот метод кажется стандартным, он обязателен при любых «зависаниях» реструктуризации. Помимо удаления временных файлов локального кэша пользователя, необходимо:
Агент сервера 1С:Предприятие.srvinfo).Список информационных баз на клиенте.Если обновление в штатном режиме вызывает ошибку, попробуйте выполнить Выгрузка информационной базы в файл .dt. При последующей Загрузка информационной базы в чистую (новую) базу данных платформа принудительно переиндексирует все метаданные. Это помогает очистить «мусорные» ссылки, которые могли возникнуть из-за сбоев при работе с Хранилище конфигурации.
Если перечисленные методы не принесли результата, необходимо настроить Технологический журнал для фиксации момента сбоя. Добавьте фильтр на события EXCP (исключения) и DBMSSQL (взаимодействие с СУБД).
// Пример настройки фильтра ТЖ для отладки
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="true" type="0" location="C:\Logs\Dumps"/>
<log location="C:\Logs\Errors" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Анализ логов поможет определить, какой именно объект метаданных (таблица или поле) вызывает сбой при попытке изменения структуры.
Ошибка jenkins backend указывает на глубокую проблему метаданных расширения. Если попытки «лечения» не приносят результата, самым надежным способом остается полное удаление расширения из конфигурации, ручная очистка остаточных таблиц (с префиксами расширения) в СУБД и последующее повторное подключение расширения к Хранилище для получения чистой структуры объектов.