Repeated bridge timeout escalation aborts concurrent tools during Inspect-heavy workloads

[null-axiom]

Summary

During concurrent OpenCode work on a large repository, ordinary AFT requests repeatedly timed out and triggered shared-bridge termination. Other in-flight tools then failed with:

[aft-plugin] bridge killed during sibling timeout — request aborted

The UI also displayed the transport's unknown-outcome warning:

it may or may not have executed. Verify actual state before re-running, and never blind-retry a mutation.

The screenshot shows this on aft_inspect. The underlying logs record nine request timeouts and three bridge kills over approximately eight minutes, concurrent with expensive Inspect-triggered Tier-2 work. Two triggering requests in the first incident are identifiable as read, not Inspect.

The failures are confirmed; analysis starving request handling is a hypothesis, not an established internal root cause.

Environment

• macOS, OpenCode Desktop 1.18.31, customized local build using the Node sidecar.
• Installed plugin: @cortexkit/aft-opencode 0.56.0.
• AFT binary: 0.56.0.
• Multiple sessions/subagents issuing tools against the repository.
• Callgraph snapshots in this workload: roughly 6,450 files and 375,000 edges.
• Incident date: September 15, 2026. All timestamps below are UTC.

Observed timeout sequence

Time	Request	Timeout	Outcome
22:43:18.090	tool_call, ID 3227 (read)	30,000 ms	Bridge kept warm
22:43:18.607	tool_call, ID 3228 (read)	30,000 ms	Restarting bridge; kill logged at 22:43:18.608
22:44:29.008	tool_call, ID 3302	30,000 ms	Bridge kept warm
22:44:29.607	tool_call, ID 3303	30,000 ms	Restarting bridge; kill logged
22:46:42.389	bash, ID 3471	25,000 ms	Request timed out
22:46:51.801	tool_call, ID 3478	30,000 ms	Bridge kept warm
22:47:10.438	tool_call, ID 3479	30,000 ms	Restarting bridge; kill logged at 22:47:10.439
22:51:24.938	tool_call, ID 3755	30,000 ms	Bridge kept warm
22:51:25.164	bash, ID 3756	25,000 ms	Request timed out

Representative log evidence

From ~/.local/share/cortexkit/aft/logs/aft-plugin.log. Session IDs and repository paths are omitted below; timestamps, request IDs, timings, and event text are retained.

[2026-09-15T22:43:06.927Z] INFO [aft-plugin] [aft] ... perf tier2 category=dead_code reuse=miss ms=17824
[2026-09-15T22:43:12.644Z] INFO [aft-plugin] [aft] ... perf tier2_callgraph_snapshot: source=callgraph_store files=6449 exports=6744 edges=374950 entry_points=192 ms=5540
[2026-09-15T22:43:18.090Z] WARN [aft-plugin] ... Request "tool_call" (id=3227) timed out after 30000ms — bridge kept warm
[2026-09-15T22:43:18.091Z] INFO [aft-plugin] ... perf tool=read total=30446ms pre=443ms bridge=30003ms post=0ms
[2026-09-15T22:43:18.607Z] WARN [aft-plugin] ... Request "tool_call" (id=3228) timed out after 30000ms — restarting bridge
[2026-09-15T22:43:18.608Z] ERROR [aft-plugin] ... Bridge killed after timeout.
[2026-09-15T22:43:18.608Z] INFO [aft-plugin] ... perf tool=read total=30385ms pre=382ms bridge=30003ms post=0ms
[2026-09-15T22:43:18.608Z] INFO [aft-plugin] ... perf tool=aft_inspect total=35442ms pre=6ms bridge=35436ms post=0ms

The bridge-kill record includes recent stderr with:

inspect-triggered cold-build slot acquired after 1856ms wait: ... kind=explicit inspect Tier-2 run
perf tier2 phases category=dead_code freshness=177ms snapshot=2807ms scan=8068ms(1 files) db=133ms(lock=0,txn=133) rollup_ms=4410 rollup=incremental projection=spliced journal_bytes=97 changed_files=1 ...

Other analysis records in the incident window include dead-code passes lasting up to 38.3 seconds and callgraph snapshots lasting up to 10.5 seconds. Long analysis duration alone is not the reported defect; the concern is concurrent tools timing out and the resulting process-wide aborts.

Expected versus actual

Expected: long-running analysis should not prevent unrelated tools on the same bridge from being serviced, or cause legitimate ongoing work to be classified as a hung bridge. If the bridge genuinely hangs, recovery should retain clear attribution and explicit unknown-outcome reporting for affected calls.

Actual: repeated timeout escalation kills the shared bridge and aborts other in-flight tools. This interrupts multiple sessions, including read-only work. The generic unknown-outcome warning is appropriate for potentially sent mutations; suppressing that warning or blindly retrying calls is not the requested fix.

Source-level interpretation

The installed bridge implementation contains the bridge killed during sibling timeout — request aborted rejection path and rejects pending requests when timeout escalation terminates the process. This is consistent with the UI error and the logged kill sequence.

Relevant upstream history:

• fix: classify timeout-aborted siblings as unknown #237: classification of timeout-aborted sibling requests as unknown outcome.
• fix: isolate standalone bridge process generations #234: standalone bridge process generations.

Reproduction direction

This is an observed workload, not yet a minimized deterministic reproduction:

1. Use AFT 0.56.0 through OpenCode against a repository with approximately 6,450 indexed files and 375,000 callgraph edges.
2. Run aft_inspect during editing/index invalidation, with multiple sessions or subagents sharing the project bridge.
3. Issue ordinary read and other tools concurrently.
4. Check whether Tier-2 analysis overlaps tool-request timeouts, followed by bridge restart and sibling aborts.

The exact scheduling, edit sequence, and affected sibling request IDs are not captured, so these steps describe conditions to investigate rather than a guaranteed reproducer.

Questions for investigation

• Can Tier-2 computation, lock ownership, or serialized dispatch prevent unrelated requests from completing or receiving progress while analysis is still healthy?
• Does the liveness policy distinguish requests waiting behind analysis from a genuinely unresponsive bridge?
• Can logs correlate triggering request ID, actual tool name, bridge generation, and aborted sibling IDs to make the failure attributable?

[aft-alfonso]

Your timeline was enough to find it, and the root cause is narrower than "analysis starves request handling" — it is a dispatch gap specific to the standalone bridge, which is what OpenCode Desktop with the Node sidecar runs.

The standalone bridge serves requests on one loop. Long-running commands are supposed to be deferred off that loop and polled, and inspect is — when it arrives as the bare inspect command. But every agent tool arrives wrapped as tool_call with name: "aft_inspect", and that wrapper routes inspect to the synchronous handler, so the entire blocking inspection (run_blocking_inspect_body) runs on the request loop. search has the wrapped form deferred; inspect never did. Your log shows it exactly: perf tool=aft_inspect total=35442ms bridge=35436ms, and the two read requests queued behind it (3227, 3228) time out at 30,000 ms, the second timeout escalates to a bridge kill, and every other in-flight call gets bridge killed during sibling timeout. So your reads were not slow — they never started.

Two things follow from that. The daemon-backed transport does not have this problem, because tool_call runs on an executor pool there; that is why it has not shown up on our own fleet. And the liveness policy is right to kill a loop that is not answering — the defect is that the loop was busy with work that should never have been on it.

Fix in progress: tool_call(aft_inspect) goes through the same deferred-and-polled path the bare command already uses, with a test that issues read while an inspect is in flight on a standalone bridge and asserts the read answers in milliseconds. Your third question (correlate the triggering request, tool name, bridge generation, and aborted sibling IDs in the kill record) is a good one and is included. Will post here when it lands.

[aft-alfonso]

Landed on main (commits ed03b631c and 3db23d21d), for the next release.

What changed, against the three things you asked:

1. Long tool calls no longer block the standalone request loop. The wrapped inspect call now goes through the same deferred path the bare command already used — and the fix covers every route in that situation (read, bash, and the LSP navigation calls too), so a read issued while a 35 s aft_inspect is running answers in a few seconds instead of timing out at 30 s. The regression test runs the real binary with a slow tier-2 inspect in flight and asserts the concurrent read finishes; putting inspect back on the loop makes it fail.

2. Cancellation works on the deferred inspect — a cancel returns true and the inspect reports interrupted instead of running to completion under a dead request.

3. When the bridge does get killed, the record says why. The kill log line and every sibling request's rejection now carry the triggering request id and tool, the bridge generation, and the list of aborted siblings with their tool names, so the next report of this shape names its cause in the log rather than in a timeline reconstruction.

Thanks for the precise timeline — it made the routing mismatch visible in one read.