bpm-crafters / bpm-crafters/process-engine-adapters-operaton
Extend lock timeouts automatically for the Operaton remote adapter
- Dominant language
- Kotlin
- Stars
- 1
- Forks
- 0
- Avg merge
- 11m
- Merged PRs (30d)
- 3
Description
> Adapted from https://github.com/bpm-crafters/process-engine-adapters-camunda-7/issues/151
Library version: 2025.08.3
### Scenario
For the Operaton remote adapter we want fairly low lock timeouts, preferably around 1 to 5 minutes, because: why would you need more for fast executions? However, all external tasks are fetched in batch, i.e., distinguishing lock timeouts per topic (thus depending on the expected load) is not possible in a single fetch. It would be nice to have if the adapter were to extend locks automatically.
### Current Behaviour
Lock timeouts are not extended.
### Wanted Behaviour
A scheduled task at the rate of roughly half the lock timeout which detects currently running external tasks and extends their lock timeouts (via the Operaton external-task `extendLock` API) as needed.
The goal is that users can set a single low timeout (e.g. 1–5 minutes) for all subscriptions as a "don't-care" value, without having to reason about lock timeouts per topic.
### Rationale
Note that being able to specify a timeout per topic (as an alternative approach) does **not** fully solve this. Consider:
* **Proper timeouts for genuinely long-running tasks, and a worker dies** (e.g. during a deployment). Tasks that were running on that worker will not be re-fetched by another worker until their locks time out — so anyone waiting on that (long-running) process has to wait even longer.
* **Improper (too short) timeouts for long-running tasks.** Another worker may fetch tasks that are still being worked on, which — without optimistic locking — can lead to bad data.
Automatically extending lock timeouts avoids both problems without imposing these technical details on users.
Contributor guide
No contributing guide indexed for this repository
Research direction
No files or tests are named. Start by locating the Operaton remote adapter and its external-task fetch and worker lifecycle, then read the external-task extendLock API; done means a scheduled task extends locks for currently running external tasks at roughly half the configured timeout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100