Поиск причин зависания при обновлении конфигурации через EDT

Проблема. При обновлении базы из 1С:EDT загрузка доходит до конца и замирает. Ошибки нет, окно не закрывается, ждать можно сколько угодно. Зависает и обычное обновление, и полная загрузка с флажком «Загрузить конфигурацию полностью». Точно так же встаёт и загрузка конфигурации из файлов через конфигуратор.

У меня это случилось на платформе 8.5.1.1302 и EDT 2025.2, файловая база, конфигурация на БСП 3.2.

Как отличить зависание от долгой загрузки

Полоска прогресса стоит на «Завершение загрузки» или на каком-то проценте. Чтобы понять, что загрузка именно зависла, а не просто долго работает, я смотрел три вещи:

• в журнале EDT последняя строка — Loading configuration, до строки Loading N configuration objects дело не доходит;
• файл базы 1Cv8.1CD перестаёт расти: размер и время изменения не меняются;
• процесс 1cv8 занимает почти целое ядро процессора, а журнал конфигуратора пустой.

Если за три минуты файл базы не вырос — это зависание. Остановка из EDT даёт DesignerDisconnectException и InterruptedException, но это просто обрыв ожидания, о причине они ничего не говорят. Хорошая новость: зависшая загрузка базу не портит, конфигурация в неё просто не записывается.

Причина

В роли было выдано право Чтение на перечисления. Его поставил не человек в редакторе, а EDT MCP Server: он без возражений записал право в файл роли Rights.rights, и EDT стал показывать его как обычное.

Но у перечислений прав нет и никогда не было — ни в текущей версии платформы, ни в предыдущих. Это видно и в EDT: у перечисления нет вкладки с правами.

А если открыть роль и попробовать добавить права для перечисления, список будет пустым.

В ролях БСП тоже нет ни одного объекта вида Enum.*: перечисления встречаются только внутри текстов ограничений доступа как значения в запросе. Пользователь видит значения перечисления потому, что у него есть права на реквизиты документов и регистров, а не потому, что ему выдано чтение перечисления.

Платформа такое описание роли не отвергает с ошибкой. Она просто останавливается внутри Loading configuration, нагружает процессор и молчит. Хватало права на одно-единственное перечисление, чтобы загрузка вставала.

Решение

Удалить из роли все права на перечисления. Найти их проще всего поиском по Enum. в файле Rights.rights роли. Блок выглядит примерно так:

Блок нужно удалить целиком, вместе с <object>. Если снять право через EDT MCP Server, может остаться пустой элемент <right> без значения, а объект так и останется в роли. После правки файла обновите проект в EDT и проверьте, что перечислений в правах роли больше нет. После этого обновление проходит за секунды.

Как искать, если причина неизвестна

Зависание без текста ошибки по стеку не найти. Работает половинное деление:

1. Уберите из проекта половину новых изменений (объекты, права, ограничения) и сложите их отдельно, чтобы потом вернуть.
2. Обновите базу. Для чистоты проверки удобнее полная загрузка: результат не зависит от того, что уже было загружено раньше.
3. Оцените результат по журналу EDT, размеру файла базы и загрузке процессора, а не по полоске прогресса.
4. Если прошло — проблема в отложенной половине, если зависло — в оставшейся. Делите дальше.

Не повторяйте загрузку с тем же составом: вторая попытка ничего нового не скажет. У меня поиск начался с объектов метаданных, но они оказались ни при чём — в итоге деление дошло до прав роли и до одной строки в ней. На поиск ушло полночи и примерно 10% месячной подписки на ИИ-агента.

По пути могут найтись и другие ошибки в метаданных. Их легко отличить: они падают сразу и пишут причину. Зависание без текста — это другой класс проблем.

Вывод

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

Инструменты MCP дают ИИ-агентам возможности, которых платформа не предусматривает: например, записать в роль то, что редактор даже не покажет. А сами агенты могут не знать таких вещей, как то, что у перечислений не бывает прав.

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