Почему хранилище конфигурации 1С не загружает обновления при захвате объектов и как это исправить?

При работе в команде разработчиков 1С хранилище конфигурации является незаменимым инструментом для совместной работы. Однако многие специалисты, особенно при поддержке конфигураций на обычных формах (например, классической «Управление торговлей 10.3»), сталкиваются со странным и крайне неприятным поведением платформы: коллега вносит изменения в объект (например, справочник Контрагенты) и помещает их в хранилище, но когда вы захватываете этот же объект, новая версия кода к вам не поступает. Вместо этого устанавливается лишь отметка о захвате, а сам модуль остается в старом состоянии.

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

Причина проблемы: как кэширование мешает синхронизации

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

1. Локальный пользовательский кэш метаданных 1С. Это общий кэш базы данных, в котором хранятся структуры конфигурации для конкретного пользователя на его рабочем компьютере.
2. Локальный кэш базы данных хранилища (папка cfgrepo). Специальный кэш конфигуратора, хранящий локальную историю версий и хэш-суммы объектов хранилища. Если хэш-сумма в этом кэше сбоит, платформа считает локальный объект обновленным и «пропускает» реальное скачивание кода при захвате.
3. Кэш самого хранилища на сервере (папка cache). Хранит готовые «снимки» версий конфигурации для быстрой отдачи клиентам. При сетевых сбоях файлы внутри этой папки могут повреждаться, из-за чего сервер отдает разработчикам устаревшие версии объектов.

Проанализируем по шагам все методы устранения этой проблемы — от простых пользовательских манипуляций до системного администрирования.

Решение 1. Очистка локального кэша базы данных хранилища (папка cfgrepo)

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

1. Закроем конфигуратор и сеансы 1С проверяемой базы.
2. Перейдем в каталог локальных данных пользователя по следующему пути:
   C:\Users\<ИмяПользователя>\AppData\Local\1C\1Cv8\<ID_базы>\cfgrepo\
3. В этой папке хранится локальная копия структуры хранилища. Полностью удалим папку cfgrepo.

Важное примечание: при полном удалении папки сотрется локальная история ваших комментариев к коммитам. Если вам важно сохранить историю комментариев, удаляйте всё содержимое папки cfgrepo, за исключением файла comments.

Начиная с платформы 8.3.15, мы можем автоматизировать этот процесс. Для быстрой очистки кэша хранилища без ручного поиска папок можно запустить конфигуратор через командную строку со специальным ключом /ConfigurationRepositoryClearCache:

"C:\Program Files\1cv8\8.3.20.1613\bin\1cv8.exe" DESIGNER /F "C:\Put_K_Baze" /N "ИмяПользователя" /P "Пароль" /ConfigurationRepositoryClearCache

Решение 2. Очистка серверного кэша хранилища (каталог cache)

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

Для устранения этой проблемы выполним следующие действия:

1. Попросим всех разработчиков временно отключиться от хранилища конфигурации. Очистка должна производиться строго монопольно.
2. Зайдем в каталог самого хранилища на сервере (путь, который вы указываете при подключении к хранилищу).
3. Перейдем в подпапку cache.
4. Вручную удалим все файлы с расширением .snp из этой папки (или полностью очистим папку cache).

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

Также очистку кэша можно произвести штатными средствами администрирования хранилища. Для этого откроем конфигуратор, перейдем в меню Конфигурация — Хранилище конфигурации — Администрирование и нажмем специальную кнопку «Очистить кэш».

Решение 3. Полный сброс локального кэша метаданных 1С

Если точечные методы не помогли, выполним стандартную процедуру полной очистки кэша базы данных. Самый быстрый и надежный способ сделать это без ручного поиска временных папок Local и Roaming — перерегистрация базы в списке запуска:

1. Запустим окно запуска 1С:Предприятия.
2. Выберем нашу информационную базу и нажмем кнопку «Удалить» (при этом физические файлы базы или настройки подключения на сервере не удаляются, стирается только запись в списке).
3. Нажмем кнопку «Добавить» и заново пропишем путь к базе данных (или параметры подключения к серверу приложений).
4. Запустим конфигуратор. Платформа создаст новый уникальный идентификатор базы и сформирует чистые файлы кэша.

Решение 4. Борьба с последствиями «динамического» обновления

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

При динамическом обновлении конфигурация базы данных меняется мгновенно, из-за чего локальный кэш конфигуратора у разработчиков часто «сходит с ума». Платформа сравнивает только хэш-суммы объектов из кэша, а не их реальное текстовое наполнение. Из-за динамического обновления хэши могут совпасть, и конфигуратор выдаст ложное сообщение «Конфигурации идентичны», хотя код модулей различается.

Рекомендация: старайтесь полностью исключить динамические обновления на базах, подключенных к хранилищу. Если такое обновление всё же произошло и привело к рассинхронизации, выполните следующие действия:

1. Полностью отключите базу данных от хранилища через меню конфигуратора.
2. Очистите локальный кэш базы данных.
3. Обновите конфигурацию базы данных стандартным («монопольным») способом.
4. Подключите базу к хранилищу конфигурации заново.

Временный обходной путь: «Костыль холостого изменения»

Рассмотрим практический прием, который поможет быстро «протолкнуть» зависший объект конкретному разработчику без прерывания работы всей команды и очистки серверов:

1. Попросим любого другого коллегу-разработчика (у которого данный объект и его код отображаются корректно) захватить проблемный объект в хранилище.
2. Пусть коллега внесет в него минимальное холостое изменение (например, поставит пробел или добавит пустой комментарий // в конце любого модуля).
3. Коллега должен поместить этот объект обратно в хранилище.

Это простое действие принудительно увеличит номер версии объекта в хранилище и пересчитает его хэш-сумму. После этого у «проблемного» разработчика платформа гарантированно увидит разницу версий и принудительно обновит код объекта при следующем захвате или обновлении.

Особенности работы обычного приложения (УТ 10.3)

Многие разработчики замечают, что на управляемых формах работа с хранилищем происходит стабильнее, а на обычных формах (например, в УТ 10.3) подобные сбои происходят регулярно. Выясним причину этой специфики:

• В режиме совместимости со старыми версиями платформы (что характерно для УТ 10.3) механизмы кэширования и контроля целостности метаданных хранилища работают по старым алгоритмам, которые содержали больше ошибок. Многие из этих багов были исправлены фирмой «1С» только в последних релизах платформы 8.3.
• В управляемом приложении клиент-серверная архитектура берет на себя гораздо больше функций контроля за синхронизацией версий метаданных, в то время как обычное приложение сильнее зависит от толстого клиента и локальных файлов кэша на диске конкретного разработчика.

Можно ли отключить кэширование конфигурации совсем?

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

Если полностью отключить кэширование метаданных, конфигуратор при каждом клике, открытии формы или переходе к процедуре будет обращаться напрямую к базе данных хранилища для чтения структуры. Это приведет к колоссальным задержкам и падению производительности работы. Открытие конфигуратора превратится в длительный процесс (как при первом запуске новой базы), а разработка станет некомфортной. Вместо отключения кэша лучше настроить автоматическую чистку временных папок cfgrepo по расписанию во внерабочее время.