После пересборки проекта происходит полный экспорт

KovAlexey commented 8 months ago

Описание ошибки

Ошибка в том что... После полной пересборки проекта (в результате ошибки, в результате очистки рабочей области) для ИБ регистрируются все метаданные к обмену. Это, очевидно, некорректное поведение. Т.к. исходные файлы не менялись, состояние синхронизации не менялось, конфиг дамп инфо не менялся.

Как воспроизвести

Выполнить полную синхронизацию
Выполнить очистку рабочей области
Или запустить обновление (что приведет к полной синхронизации), или же закрыть EDT и открыть файл ".metadata.plugins\org.eclipse.core.resources.projects\project\com._1c.g5.v8.dt.platform.services.core\refs\heads\branch\infobase-synchronization\6f0805f4-e7dc-4a21-b648-e6d5391d32ec\SynchronizationData.store\store" Где можно увидеть все метаданные.

Скриншоты

No response

Ожидаемое поведение

Отсутствие полной полного экспорта проекта, т.к. обновление по прежнему не оптимизировано и выполняется долго. Должно выгружаться только то, что было зарегистрировано к выгрузке на момент очистки рабочей области.

Как минимум потому что сборка\очистка проекта никак не влияет на подключенную ИБ и исходные файлы непосредстенно проекта.

Лог рабочей области

В данном случае лог после сбоя (закрыл, открыл проект и все упало) Но в случае полной очистки принципиально отличий нет

log.zip

Версия 1С:EDT

2023.2.4

Операционная система

Windows

Установленные плагины

1C:Code style V8, 1C:SSL-support

Дополнительная информация

Способ обхода:

Подмена файла store на синхронизированный вариант

KovAlexey commented 8 months ago

На случай, если вдруг что-то действительно сбилось в состоянии синхронизации - у нас всегда есть "Полная выгрузка", которая запускается руками. Но при любой пересборке делать полный экспорт - очевидно избыточно.

MaksimDzyuba commented 8 months ago

@KovAlexey, здравствуйте, вот Вы пишите "Это, очевидно, некорректное поведение." Я с Вами очень не согласен, то, что не менялись файлы, не говорит ничего о том, что не поменялись объекты. Ведь кроме файлов, есть еще рассчитываемые данные, например, таблицы объектов метаданных. От этих рассчитываемых данных зависит то, как формируется конечный xml для отправки в платформу. Поэтому текущее поведение оно не ошибочное, оно может быть не самое удачное, но точно не ошибочное, как Вы тут пишите. Поэтому я перевожу данную задачу из ошибки в задачу, у нас не в далеких планах есть задача на реализации более производительного подхода.

KovAlexey commented 5 months ago

Ведь кроме файлов, есть еще рассчитываемые данные, например, таблицы объектов метаданных. От этих рассчитываемых данных зависит то, как формируется конечный xml для отправки в платформу.

Честно сказать, прям поле для UB какое-то. Как можно ожидать стабильной работы системы, если два одинаковых набора файлов могут дать разный xml после конвертации?

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

1C-Company / 1c-edt-issues