если логируется, то можно посмотреть в таблице с логами.
https://docs.camunda.org/manual/7.15/user-guide/process-engine/history/#glossary-of-operations-logged-in-the-user-operation-log
Есть событие CreateHistoryCleanupJobs например или какие другие из таблички.
select * from act_hi_op_log where operation_type_ = 'CreateHistoryCleanupJobs'
Не уверен правда что тут есть подходящее, но я бы попробовал это

Спасибо всем большое, теперь более понятно куда двигаться с чисткой)!!

Всем привет. Внутри Service Task вызывается делегат, в котором используется механизм Retry Spring-а. Когда ретраи отрабатывают, сама таска, судя по всему, почему-то перезапускается несколько раз, вызывая новые ретраи. Подозреваю, что это как-то связано с превышением времени ожидания выполнения, но камундовский параметр default-number-of-retries = 1, поэтому не совсем понимаю, почему происходит перезапуск. Подскажите, пожалуйста, кто знает, в чём может быть причина и как это можно поправить?

Здравствуйте!

По умолчанию Камунда перезапускает активности с ошибками:

> If a job fails, the default behavior of the Camunda Platform engine is to retry every job two times.

Источник: https://camunda.com/blog/2021/04/where-is-the-retry-in-bpmn-20/

В Вашем случае есть два варианта:

1. Отключить спринговый механизм перезапуска.
2. Отключить камундовский механизм перезапуска.

В указанной статье есть ссылки как сделать пункт 2.

Да, но меня скорее интересует механизм перезапуска по таймауту. Если превышено какое-то время, отведенное на выполнение активности, камунда кидает свою ошибку? Или перезапускает активность?

У камунды нет таймаута на выполнение активности. Можно навесить таймер ивент и логику какую-то на него.

То есть активность может выполняться сколько угодно долго?

Верно. Процессы могут жить годами.

Исключение, наверное, connector'ы, но они в принципе геморные и я б не рекомендовал их использовать. Лучше в делегает обращение к внешним сервисам сделать.

А параметр lockTimeInMillis тогда зачем? Я так понял, это как раз мой случай - "And if you queue up more jobs than you can finish within the lock timeout (), jobs are timed out and will be executed twice"
https://camunda.com/best-practices/performance-tuning-camunda/#_tuning_the_job_executor

Это не совсем тот таймаут. У вас джоб-экзекутор в который попадают таски с диаграммы на исполнение. Когда экзекутор берёт таску в исполнение он лочит её (чтоб другой инстанс не начал выполнять ту же работу). Если таска не успела завершиться за отведённое время, она разлочится и вернётся в очередь на исполнение. При этом, для всех, кроме первого завершившегося, исполнений будет выброшен OptimisticLockException.

В вашем случае, я так понимаю, ретраи происходят и от спринга, и от камунды?

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

Причина может быть такая:
Спринг пытается выполнить запрос, потом его ретраит, в итоге падает, если ретраи закончились и выбрасывает Exception. Это техническая ошибка и по идее должен регистрироваться инцидент на таске. Но если Retry Time Cycle не указан на диаграмме и не задан в коде, то по умолчанию мы будем пытаться выполнить эту же операцию ещё 2 раза. Т.е. ещё два раза вызовется спринг со своими ретраями и только потом упадёт инцидент.

Как отключали камундовские ретраи?

default-number-of-retries переставил на 1

Retries = 1, значит после падения он будет пытаться выполнить его ещё 1 раз. Нужно выставить в 0 и убедиться, что на диаграмме это значение не перегружено

Я тоже сначала так думал, но при таком значении процесс вообще не запускается. По ходу должна быть всё-таки единица - https://jira.camunda.com/browse/CAM-8709 . Описание поправили, но сильно понятнее не стало...

Да, действительно, немного попутал с JobRetryTimeCycle 😕

А с нагрузкой проблем нет?