You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by "Serge Huber (Jira)" <ji...@apache.org> on 2026/07/18 05:35:00 UTC
[jira] [Created] (UNOMI-967) Clustered scheduler locks and recovery are still unsafe under node races
Serge Huber created UNOMI-967:
---------------------------------
Summary: Clustered scheduler locks and recovery are still unsafe under node races
Key: UNOMI-967
URL: https://issues.apache.org/jira/browse/UNOMI-967
Project: Apache Unomi
Issue Type: Bug
Components: unomi-3.1.0, unomi(-core)
Affects Versions: unomi-3.1.0
Reporter: Serge Huber
Assignee: Serge Huber
Fix For: unomi-3.1.0
h2. Summary
In a multi-node Unomi cluster, scheduled tasks can still lose locks incorrectly, run on the wrong node after a crash, or stay stuck after a node stops. Operators cannot rely on exclusive tasks and recovery without risking duplicate or stranded work.
h2. What is going wrong today
* A node can clear or overwrite another node's lock during release or completion races
* Crash recovery can dispatch work from non-executor nodes, or leave tasks stranded after shutdown
* Exclusive (non-parallel) tasks default and type-level checks are not strong enough for operators who expect one active run
* Lock verification false-negatives after CAS can leave locks held or drop a peer's claim
* Unit coverage around managers, multi-node isolation, and these races is too thin to catch regressions
h2. Impact
* Duplicate or missed task execution in production clusters
* Tasks stuck in RUNNING/CRASHED until manual intervention or lock timeout
* Hard-to-reproduce CI flakes when scheduler races are involved
h2. Who is affected
* Operators running Unomi with more than one scheduler/executor node
* Contributors changing the scheduler who lack regression tests for cluster races
h2. What good would look like
* Exclusive tasks do not steal or wipe a peer's valid lock
* Terminal and crash transitions only commit when the node still owns the work
* Non-executor nodes can mark crashes but do not dispatch recovery unless the task is meant to run on all nodes
* Shutdown after prepare does not leave orphan locks
* Solid unit tests cover lock, execution, recovery, provider shutdown, and multi-node isolation races
* Scheduler manual documents states, locks, and ES/OpenSearch OCC expectations clearly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)