Ну в external task вполне себе вручную создаются и ведут себя предсказуемо 😂

Эт потому что там альтернативы нет

Тогда вообще не очень понятно для каких целей оставили возможность создавать кастомные инциденты. Если например создать инцидент и следом выбросить exception, по штатный инцидент Failed Job перекроет кастомный судя по всему. О кастомном, возможно, останется только запись в истории

Потому что можно инциденты кидать там, где нет процессов

Вот это не понял) приведи пример, пожалуйста

Да вот есть какой-нибудь рест ендпоинт кастомный и на него прислали какую-то дичь

Можно вместо экшепшена в лог

Кинуть инижчиент, чтоб кто-то глянул

Спасибо, теперь понял)

Кстати, наши вакансии теперь есть и на hh.ru

Ну и ссылки тогда надо публиковать то

Подскажите пожалуйста как правильно положить составной объект в external client  и вычитать как variable на сервере камунды?

Нет под рукой примеров. Смотрите в сторону spin-core. Но вообще если появляется такая потребность, то лучше наверное уходить в сторону внешнего хранилища объектов. Как рекомендует Денис - stateless context

Мне просто нужно вернуть респонс процесса через рест, я его запускаю повесив эндпойнт в камунде на запуск процесса, и когда он завершится складываю в variables, а на сервере ScheduledExecutorService ждет пока появится переменная с ответом и возвращает респонс

Да я нашел как в json с помощью  spin  упаковать

Вот это реализовываю

Очень сложно. Посмотрите DeferredResult.

Но вообще, если я правильно понимаю у вас будет так: Клиент шлет rest запрос на камунду. Этот rest стартует какой-то бизнес-процесс, который управляет некоторой группой микросервисов, реализует сагу, в конце БП формируется некоторый ответ, который должен вернуться клиенту? Все это время клиент держит подключение и ждет ответ?

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

Всем привет!

Подскажите, пожалуйста, по табличке *act_hi_job_log*.

В таблицу пишется очень много строк (включено полное логирование) с типами job: batch-monitor-job, batch-seed-job, instance-deletion, historic-instance-deletion и т.д.

Есть ли стандартные механизмы, чтобы чистить данные строки ?

Для строк, помечаемых значениями дат *removal_time_*, отрабатывает стандартный механизм job очистки истории.

Хотелось бы узнать про строки в данной таблице, не помечаемые датами в поле *removal_time_*.

Спасибо.