-
Feature Request
-
Resolution: Fixed
-
L3 - Default
-
7.11.2
-
None
When there are multiple workers querying the same topics, they may select the same task for acquisition. For each task, the corresponding execution is selected in order to collect its variables. In concurrency situations, the execution may not exist anymore, which lets the fetch and lock command fail with a NullValueException. As the absence of the execution indicates a concurrent modification, this scenario should be treated like OptimisticLockingException when locking the task, i.e. the task should be removed from the result set and the command should not fail.
Example:
Let's assume there are 5 tasks (tasks 1-5) in the database and there are two workers (worker 1 and worker 2).
Let's also assume both workers send a fetch and lock request concurrently and
- worker 1 attempts to lock Tasks 1-4
- worker 2 attempts to lock Tasks 4-5
Current behavior
Assuming that worker 1 commits first and immediately completes task 4 (while worker 2 is still in the fetch and lock command), worker 2 may fail when selecting task 4's execution, which lets the fetch and lock command fail.
Proposed behavior
Worker 2 should ignore the conflict on the execution and come back with task 5.
Context
This is already the implemented behavior in case of concurrent modifications on the task itself.
