#935 (Задача 97) Проблема с экспортом (как на сервер так и в файл) процесса с композициями

[vromav]

(Наверное как-то связана с #931)

Не получается экспортировать процесс в файл и на сервер.

Создал 4 композиции, и 3 элемента подпроцесса, делал подключение композиций в подпроцесах, а затем неиспользуемую композицию удалил. Закрыл процесс, затем попробовал открыть и экспортировать, получил ошибку:

java.lang.RuntimeException: No file found for 4 (sub4)

[vromav]

Зависимость пока не выявил

[Dofs]

C 931 не связана, т.к. там изменения затронули только серверную часть.

[vromav]

Не могу повторить, но процесс у меня остался в редакторе. Если какие-то данные из него могут помочь, сообщи.

[Dofs]

Просьба заархивировать папку с файлами БП и выложить сюда.

[vromav]

Сценарий воспроизведения

• Создать процесс с композицией
• Сохранить процесс
• Выделить на графе элемент подпроцесс и создать новую композицию, откроется новое окно с композицией
• Закрываем основной процесс, на предложение сохранить – отказываем, закрываем и вкладку с подпроцессом
• Открываем главный процесс, при попытке экспорта возникает ошибка

[vromav]

UPD: но если переоткрыть редактор, то ошибка в данном процессе больше не возникает.

[Alexeev Vitaly]

Непосредственная причина падения:

ru.runa.gpd.ProcessCache.getProcessDefinitionFile(ProcessDefinition processDefinition);

Поиск второго, не сохраненного процесса композиции выполняется по условию:

if (Objects.equal(processDefinition, entry.getValue()))

Что равносильно сравнению по хэшу, т.к. БП-дифинишн не имеет перегрузки equals.

На этот момент файл в кэше имеется, но БП-дифинишн уже другого экземпляра, пересозданного при открытии БП, поэтому хэш инстансов не совпадает и сравнение заканчивается фейлом.

Перегружать equals стремно, опять что-нибудь где-нибудь поломается, что этот equals косвенно использует. Можно перегрузить hashCode, но тоже стремно.
Наверное лучше всего выполнять дополнительное сравнение в этом месте ProcessCache по другим критериям.

[Alexeev Vitaly]

[r6231] - бранч для работ по тикету

[Alexeev Vitaly]

[r6232] - реализация уникальных хэшкодов БП в пределах воркспейса на относительном пути к файлу

[vromav]

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

Сценарий воспроизведения:

• Создать процесс: начало – композиция - окончание, выбрать роль для "Начало"
• Сохранить процесс
• Создать композицию
• Композицию оставляем пустую, никакие элементы не добавляем
• Закрываем основной процесс, не соглашаемся на изменения
• Закрываем пустую композицию

• Открываем главный процесс, видим замечание “Выберите подпроцесс”,

• выбираем существующую пустую композицию

• Открывается пустая композиция,
• Кидаем элемент Начало и Завершение потока в композицию, сохраняем,
• Закрываем композицию, сохраняем основной процесс, видим что ошибок и замечаний нет
• Вызываем экспорт процесса
• Получаем ошибку при экспорте: “Процесс должен иметь начальное состояние”, хотя подпроцесс имеет элемент Начало

Опять же, после перезапуска DevStudio, проблема не наблюдается.

[Alexeev Vitaly]

Несмотря на ошибку “Процесс должен иметь начальное состояние” в файл такой процесс экспортируется, на сервер отказывается, в целом все воспроизводится.

Наверное как-то связано с тем, что БП, либо композиция не апдейтит состояние, сохраненное в кэше.

[Alexeev Vitaly]

Проблема не связана с кешированием БП, и ее причина в корне отличается от причины ошибки данного тикета. Точная причина вообще пока не понятна - каким-то мифическим способом один и тот же валидатор одного и того же файла при сохранении данных в файл композиции возвращает положительный результат валидации, а при попытке экспорта - ошибку, как будто данные на самом деле не сохранились.
Разбор перенес в [#1024]

[Alexeev Vitaly]

[r6261]

• удаление композиций из кэша при удалении БП
• мелкие правки компарации БП по хэшкоду

[Alexeev Vitaly]

[r6262]
удаление отладочного кода

[Alexeev Vitaly]

[r6263] merge [r6262]

[Alexeev Vitaly]

[r6264] - удаление девелоперского бранча