CAMEL-25010: camel-core - Supervising route controller: do not start a route stopped during its restart attempt

[allthingssecurity]

Description

CAMEL-25010

The restart attempt of DefaultSupervisingRouteController only checked CamelContext.isRunAllowed() and then called doStartRoute, which takes the controller lock and starts the route. stopRoute takes the same lock and cancels the route's restart task (RouteManager.release). Cancelling only prevents future attempts: BackOffTimerTask.run() checks the status once, on entry.

So an attempt that was already running started the route after stopRoute had returned. This happens whenever the attempt waits for the controller lock during the stop, and the lock is shared by all routes, so a slow stop of any other route is enough. The route then ran without supervision (it has no restart task any more), and nothing reported it.

This change: the attempt now checks under the controller lock, before it starts the route, that:

• its task is still the route's restart task (routes.get(r) == task);
• the task is still active (a manual stop or start cancels it);
• Camel is not stopping.

If any check fails, it logs that the attempt was cancelled and gives up without starting the route. RouteManager.start runs under the same lock, so a new task is always registered before its first attempt can check.

Tests: new DefaultSupervisingRouteControllerStopWhileRestartingTest. A route fails to start. Its first restart attempt is held in the RouteRestartingEvent notifier while the cause is fixed and the route is stopped manually. The attempt is then released, and the route must stay stopped. Latches and Awaitility, no sleeps. Without the fix:

AssertionFailedError: expected: <Stopped> but was: <Started>

With the fix it passes. *BackOff*,*Supervising*,*RouteController* in camel-util, camel-core and camel-management: all pass.

Found with a TLA+ model of the supervising route controller, then reproduced against the real classes, also without holding any thread: route r1 waits to restart while stopping route r2 holds the controller lock (3 of 3 runs restarted r1 after stopRoute("r1") returned). With only this change, "no restart after the user stopped the route" holds in the model with up to 3 user operations and 3 restart tasks (36k states). The same harness scenarios now leave the route stopped.

Related:

• CAMEL-25001: camel-core - Supervising route controller: an exhausted route stays unhealthy after it is started manually #26859 (CAMEL-25001) changes RouteManager.release(). This change is in the attempt of RouteManager.start(). The two apply together without conflicts.
• CAMEL-25008, CAMEL-25007: camel-core - Supervising route controller: fix a deadlock and a lost restart task #26867 (CAMEL-25007, CAMEL-25008) fixes two other issues found by the same model: a deadlock between the restart task lock and the controller lock, and a cancelled restart task that completes twice and removes the route's new restart task. This change already stops such an orphaned task from starting the route, but the route's restart state and hasUnhealthyRoutes() stay wrong until CAMEL-25008, CAMEL-25007: camel-core - Supervising route controller: fix a deadlock and a lost restart task #26867 is merged. A cancelled attempt that gives up here also completes its task, and CAMEL-25008, CAMEL-25007: camel-core - Supervising route controller: fix a deadlock and a lost restart task #26867's routes.remove(r, task) makes sure that doesn't remove a newer task. The two PRs touch different parts of the file and merge without conflicts.

Target

• I checked that the commit is targeting the correct branch (Camel 4 uses the main branch)

Tracking

• If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

• I checked that each commit in the pull request has a meaningful subject line and body.
• I have run mvn clean install -DskipTests locally from root folder and I have committed all auto-generated changes.
  (I built and tested the affected modules, including the formatter and import-sort plugins. I did not run the full root build.)

AI-assisted contributions

• If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., Co-authored-by trailers) and the PR description identifies the AI tool used.
  This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a Co-Authored-By trailer.

Claude Code on behalf of allthingssecurity

🤖 Generated with Claude Code

[gnodet-bot]

Solid concurrency fix. The race between the restart attempt and a concurrent stopRoute is correctly closed by acquiring the controller lock before the guard check and holding it through doStartRoute. Three guard conditions (routes.get(r) != context, task status, isRunAllowed) are necessary and sufficient. Reentrant lock prevents deadlock with doStartRoute's own lock acquisition. Event notification correctly stays outside the lock to avoid lock-inversion with listeners. The test faithfully reproduces the race via RouteRestartingEvent interception with latches — no timing fragility.

This review was generated by an AI agent, Hermès on behalf of @gnodet.