[2.0] fix(search): honor a reindex stop that lands before the job starts (#35183)

[manerow]

Fixes #35182

Backport of PR #35183 to 2.0, in its smaller form.

Problem

Stopping the Search Indexing app in the first seconds of a run did not stop it. The reindex still ran, and the run could stay Running for good. In Collate, Admin Ops then refuses every new reindex with a 409 while the app looks busy.

Why it happened

A run is built as a chain: orchestrator, then strategy, then executor, then the distributed job. A stop only reached the pieces that already existed. A stop that arrived while a piece was still being created was lost for that piece and everything after it. When it was lost at the executor, the job was started with nobody working on it, another server adopted it and indexed everything, and nothing ever closed the run.

What this PR changes

Each piece now passes on a stop that arrived before it created the next one:

• The orchestrator stops the strategy it just created if a stop already came in.
• The strategy does the same for the executor it just created.
• The executor never starts a job that was stopped before it started. It asks the coordinator to stop the job, releases the reindex lock and returns.

On main, PR #35183 goes one step further and gives the whole run one shared stop signal instead of these hand-offs. 2.0 gets this smaller version because it is a patch line: the change stays inside three classes and keeps every constructor as it is.

How it was tested

• The commit is the first commit of PR #35183 and cherry-picks cleanly.
• The reindex unit tests on 2.0 pass (158), including three new ones, one per hand-off.
• On main, the same change made Collate's AdminOpsApiIT pass where it failed like Collate CI, with the stop forced into both windows.

[github-actions]

✅ PR checks passed

The linked issue has a description and all required Shipping project fields set. Thanks!

[gitar-bot]

Code Review ✅ Approved

🟡 Medium risk · Propagating early stop signals and releasing the reindex lock could prematurely halt indexing if a stop is observed during job setup.

Fixes the Search Indexing app so a stop requested in the first seconds of a run is honored at each hand-off in the orchestrator, strategy, and executor chain, instead of being lost and leaving the run stuck in Running. No issues found.

Review coverage

📋 Rules No rules evaluated

🧪 Functional validation Not enabled · Set up

🤖 Auto-approval Not enabled · Set up

Options

Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source}