Всем привет! Интересный кейс есть с камундой, external-tasks, забираются из process-engine через fetchAndLock, запрос был выполнен с lockDuration = 1 сутки, т.е. задачи будут в течении суток висеть залоченными под того кто вычитал, а после вернуться в очередь и будут снова доступны.
Теперь вопрос, можно ли как-то в рантайме снять лок на задачи раньше  (чем наступит таймаут)?  Так как задачи были потеряны системой, которая их непосредственно выполняет

Есть POST /external-task/{id}/unlock
Но он может сделать это по одному, видимо решение где-то в области собрать в бд проблемные и скриптом прогнать анлок

Похоже, сам задал, сам ответил. Тогда вопрос такой, как посчитать оптимальный lockDuration? Есть ли тут какие-то бест-практис)

Камунда гуру советуют не опираться на lock duration. Лочить «на года», и разруливать все ситуации с тасками «своими силами»

Что значит у каждого процесса своя БД?

У каждого своя ДБ Схема, те каждый имеет свой ПроцессЭнджин, которые пишут все эвенты в разные бд

Как у процесса может быть своя схема?

Или это отдельные приложения?

У каждого своя ДБ Схема, те каждый имеет свой ПроцессЭнджин, которые пишут все эвенты в разные бд

А приложение одно?

Нет

Ну, получается у вас просто много приложений?

Тогда через external task их дружить норм будет

Можно и так сказать, что одно приложение может использовать другое приложение

На эндЭвент вешать external task ?

Я думал, повесить слушателя на таблицу Процесса 'С', а потом записывать результат в какой нить MQ

Вот у нас ребята делают так https://m.habr.com/en/company/tinkoff/blog/490656/

Спасибо, похоже на нашу архитектуру, почитаю как вы справились

Для отказоустойчивости разве норм использовать камунду?

Там же запись в базу медленная, как на счёт zeebe?

А не записывайте в базу ничего