Repository navigation
core: tool failure message loses the reason when the 60m idle eviction interrupts a run #52597
Description
Description
When a run is interrupted because its location was evicted after 60 idle minutes (#51343), the tool failure for the interrupted part reports only the generic "Tool execution interrupted". The reason is known at that point — the run coordinator records reason: "inactivity" — but it never reaches the message, so from the model's side the interruption looks arbitrary and unrelated to the eviction.
This is about the message, not the policy: whether the eviction should interrupt parked work, and whether the 60-minute deadline should be configurable, are #51343's questions.
OpenCode version
2.0.8
Steps to reproduce
- Start a session and leave it parked (e.g. on the
questiontool) long enough that its location hits the 60-minute idle deadline. - The location is evicted and the run is interrupted.
- The tool failure reports "Tool execution interrupted" — no mention of the eviction.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Oct 2, 2026
This issue might be a duplicate of existing issues. Please check:
thiago-carneiro commentedon Oct 2, 2026
Not a duplicate, in my view: #51343 tracks the eviction policy (whether idle eviction should interrupt active work, and the hardcoded 60-minute deadline), while this issue is only about the reporting — when eviction does interrupt a run, the unsettled tool failure says just "Tool execution interrupted" and the reason never reaches the message. #52587 fixes that narrow part; the policy questions stay in #51343.
SamSpiri commentedon Oct 3, 2026
Related failure mode for the same 60-min eviction — the interruption reason is lost, which can mask this class of bug.
On v2.0.22 a background shell job outlived its location's 60-min idle TTL. Eviction interrupted the location-scoped completion watcher, so the job's completion notification was never delivered and the session stayed idle. From the user's perspective the run just "stopped" with no reason surfaced.
The eviction already passes
reason: "inactivity"toexecution.interrupt(...)(location-activity.ts:65). If that reason were carried into the surfaced failure/interruption message, this notification-loss case would at least be distinguishable from an ordinary failure or a user interrupt — which is precisely the ambiguity this issue is about. Making the reason visible on any work touched by the sweep, including background-job owners, would help.