А почему используется boundary event, а не catch event? Может ли таска из-за этого завершаться дважды?

boundary это ограниченный, interrupting это прерывающий

Есть процесс (см. рисунок выше), который останавливается на таске Wait и ждет таймера (в данном случае долгий интервал - дни).

В табличке act_hi_job_log до этого момента все ок - одна запись со статусом (job_state_) = 0 (created).
Ветка одна, нет параллельных веток до таски Wait.

Далее, срабатывает таймер через Х дней, и ветка процесса отрабатывает 2 раза.
В табличке act_hi_job_log - две записи, одна из которых со статусом = 2 (success),
другая - со статусом 1 (failure), и job_exception_msg_ = 'ENGINE-03005 Execution of 'DELETE TimerEntity[xxxxxx]' failed. Entity was updated by another transaction concurrently'.

Соот-но вторая ветка завершается неуспешно.

Но даже в этом случае выполняются таски Call service X, Call service Y и далее по ветке.

Конфиги Camunda - все по дефолту.
Причем данная ситуация достаточно редкая.

Подскажите, кто сталкивался с таким, в чем может быть причина срабатывания таймера более 1 раза,
что можно донастроить, чтобы ветка отрабатывала гарантированно 1 раз ?
(версия Camunda = 7.10, поднята в OpenShift, смасштабирована в 4 пода)

возможно две ноды начали обрабатывать это таймер одновременно, и одна наткнулась на concurrency

если никаких побочных эффектов нет (кроме записи в act_hi_job_log) - то тогда вроде нормально все) ну чисто логически

хотя нет, тут чистый concurrency (один и тот же TimerEntity)

Хмл покажите