Serialize ChoicesFrom lookups and protect QuPath worker ownership across app/tool changes #19

Failure mechanism

The dialog can launch one background lc-choices thread per ChoicesFrom parameter when resolveChoices() runs (LabConstrictorTools.groovy lines 551–562). Every thread executes:

ensureWorker(app, appName)
def outcome = worker.run(p.choices_from.tool as String, request, null)

(lines 578–603).

ensureWorker() (lines 1187–1195) reads and overwrites the shared worker and workerApp fields without a lock or single executor. An app switch or rescan can occur while a choices thread is still running. The tool run calls the same unsynchronized ensureWorker() from its own thread.

Consequences

• Two source-choice requests can both conclude that the worker is missing and start different worker processes. One process may be orphaned while a different thread calls worker.run() on the newer shared field.
• A late choices request from app A can replace the worker used by an active tool or by app B. The tool request may then go to an incorrect interpreter, fail, or be cancelled through the wrong currentTask.
• Choosing a new tool resets choiceSeq, so the numeric generation counter alone does not provide a unique app/tool generation identifier for a late response.

The code comments say each source request has a sequence number, but that protects choice presentation, not worker ownership.

Proposed fix

Use a dedicated serialized worker controller (or an app-scoped worker pool with explicit per-worker locking). Capture the worker instance and app identity for the full lifetime of each submitted job. Invalidate stale ChoicesFrom tasks when app or tool changes; avoid replacing a running tool's worker.

Acceptance criteria

• Two simultaneous ChoicesFrom lookups create no duplicate/orphan processes and return to the correct controls.
• App or tool switch during a delayed choices lookup cannot replace the active run's worker or apply the old options.
• Starting an analysis while a choices lookup is in flight does not execute it in the wrong application environment.
• Regression test exercises a delayed ChoicesFrom tool alongside a normal run and verifies worker identity and cleanup.

Priority: P1 — cross-application worker race, possible wrong tool execution. Source-traced, not runtime reproduced on the GUI.