Standalone aft_search cannot be cancelled and blocks the whole bridge while waiting

[trim21]

Problem

Over the standalone NDJSON transport, a semantic_search request can neither be cancelled by the client nor avoided blocking sibling requests.

1. Search runs inline on the single request thread

The NDJSON main loop dispatches synchronously (crates/aft/src/main.rs:314, dispatch_outcome called inline). With AFT_WAIT_FOR_SEMANTIC_READY=1 (set by harness plugins so the first search doesn't return partial results), wait_for_semantic_index_before_search (main.rs:914-953) sleeps in a loop for up to AFT_WAIT_FOR_SEMANTIC_READY_MS (600s in the pi plugin) while the index builds. During that window every other command — status polls, outline, other tool calls — queues behind it, because they all share the one request thread. A big-repo cold build (~2h) means every search during the build hangs ~10 minutes and then errors with semantic_index_timeout, and takes the rest of the bridge down with it.

2. Cancellation infra exists but isn't reachable standalone

search_cancellation_requested() (crates/aft/src/commands/semantic_search.rs:191 → executor current_job_cancelled) is only wired for the subc/executor job path (route-closed cancellation). There is no wire-level cancel command for NDJSON: when the client gives up, the child keeps waiting/embedding to completion. Harness-side, the best a client can do is abandon the request locally — the search keeps occupying the request thread.

Proposal

1. Route long-running read commands (semantic_search, maybe others) through deferred dispatch on the existing executor so JobCancellation applies; keep the response delivered via the pending-response path already used by inspect.
2. Add a wire cancel_request { id } command for standalone so clients can propagate user aborts.
3. Honor cancellation in wait_for_semantic_index_before_search (wake the 250ms sleep loop on cancel) and in the query-embed path.

Even without (2), (1) alone removes the collateral damage: a stuck search would no longer block status polls and sibling tool calls.

[aft-alfonso]

Confirmed with one correction. The core findings are exact: standalone NDJSON dispatches semantic_search inline on the single request thread, and search_cancellation_requested() only observes executor-job cancellation, which the NDJSON path never arms — so a slow query-embed blocks sibling requests and client abandonment changes nothing server-side.

The correction: neither harness plugin sets AFT_WAIT_FOR_SEMANTIC_READY — that env (and its 600s budget) is armed only by our benchmark and integration harnesses, so the production standalone worst case is the query-embed budget (semantic.query_timeout_ms, clamped 500ms–15s, default 3s), not a 10-minute park. Still a real defect: 3–15s of head-of-line blocking per search on a single-threaded loop is exactly the collateral damage you describe, just with a smaller constant.

Your proposal is the shape we'll build, in order:

1. Deferred dispatch for semantic_search through the existing pending-response path (the same seam inspect and bash orchestration already use), which unblocks status polls and sibling calls — this is the bulk of the value.
2. Cancellation honored in the wait loops and the query-embed path via the deferred job's cancellation token.
3. A wire-level cancel for standalone, wired plugin-side to the host abort signal (OpenCode hands tools an AbortSignal; we already use it to abort in-flight bash) so user aborts propagate instead of orphaning the request server-side.

Queued on our side — thanks for the precise report; both this and #280 read like they came from real production use, which is the most useful kind.

[aft-alfonso]

Landed on main. Standalone semantic_search now defers through the pending-response path (the same seam inspect and bash orchestration use), so sibling requests proceed while a search is in flight — measured sibling status latency during an in-flight search went from ~650ms to 0ms. Cancellation is armed end-to-end: the executor's cancellation token is bridged to the standalone worker (so the existing checks observe it unchanged), the ready-wait and query-embed loops wake on cancel, and a native cancel_request {id} command is wired plugin-side to the host abort signal so user aborts propagate instead of orphaning the request. Response bytes are transport-invariant (locked by a parity test). Ships in the next release — thank you for the precise report and the proposal order, which is exactly what we built.

[aft-alfonso]

Shipped in v0.55.0: standalone aft_search defers through the pending-response path with cancellation, so sibling requests proceed while a search is in flight (sibling status latency measured 650 ms → 0 ms). Closing; reopen if a standalone bridge still blocks behind a search on 0.55+.