bug(build): transactional snapshot/rollback ConfigDumpInfo.xml on failed build

[korolevpavel]

Окружение

Проверено на официальном GitHub release asset v0.5.2-pre.1:

• macOS arm64;
• локальная файловая ИБ;
• format: DESIGNER;
• builder: DESIGNER;
• исходники Designer XML.

Проблема

build запускает Designer с:

/LoadConfigFromFiles <source> -updateConfigDumpInfo

Даже если загрузка завершается ошибкой либо command timeout становится pending до safe point update_db_cfg, платформа уже успевает переписать tracked ConfigDumpInfo.xml.

В минимальном сценарии изменялся один объект/модуль, но после неуспешного build получен глобальный diff ConfigDumpInfo.xml — десятки тысяч добавленных и удалённых строк с новыми configVersion несвязанных объектов.

Runner сообщает, что выполнение остановлено до update_db_cfg, однако:

• исходный ConfigDumpInfo.xml не восстанавливается;
• backup/recovery artifact не возвращается;
• повторный запуск начинается с уже загрязнённого source tree.

Аналогичный глобальный служебный churn возникает после успешного full load, хотя содержательный source diff ограничен несколькими объектами.

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

Неуспешная операция

Перед /LoadConfigFromFiles -updateConfigDumpInfo сохранить byte-exact snapshot файла.

Если load:

• завершился ошибкой;
• был отменён;
• получил timeout до следующего safe completion point;
• не дошёл до успешного update_db_cfg;

runner должен автоматически восстановить исходный файл либо вернуть явный recovery artifact и typed recovery status.

Успешная операция

Нужен opt-in target-scoped режим, например:

build:
  configDumpInfoStrategy: preserve-unrelated

Он должен оставлять platform-generated current records только для реально загруженных metadata roots и их дочерних entries, сохраняя baseline records остальных объектов.

Никакие UUID или configVersion не должны конструироваться вручную: источники merge — только baseline и успешный platform output.

Критерии готовности

• failed load оставляет ConfigDumpInfo.xml byte-identical baseline либо возвращает применимый recovery artifact;
• timeout между load и update_db_cfg покрыт тестом;
• JSON result сообщает backup, recovery action и число изменённых CDFI entries;
• scoped strategy отклоняет неожиданные/unrelated entries;
• сохраняются BOM, EOL и terminal-newline policy исходного файла;
• повтор операции идемпотентен;
• небольшой target-scoped build не оставляет глобальный configVersion churn.

[korolevpavel]

Scope split approved on 2026-07-26. This issue now covers only transactional byte-exact snapshot and recovery of ConfigDumpInfo.xml when Designer load/update fails, is cancelled, or times out before the UpdateDBCfg safe point. The target-scoped successful-build reconcile (preserve-unrelated) is tracked separately in #46.

[korolevpavel]

Проблема сохраняется в обезличенном downstream benchmark.

Симптом: failed build с timeout before update_db_cfg safe point оставлял ConfigDumpInfo.xml изменённым после /LoadConfigFromFiles -updateConfigDumpInfo. Перед повтором файл был clean/matched baseline; после failed attempt появлялся глобальный служебный churn на десятки тысяч строк, не связанный с целевым изменением. Автоматического rollback/recovery artifact со стороны runner в observed flow не было; файл приходилось очищать вручную из Git baseline.

Клиентские исходники, локальные пути, job IDs, строки подключения и данные ИБ не публикую. Это подтверждает, что rollback/snapshot проблема при timeout before safe point всё ещё воспроизводится.