Repository navigation
A task whose plan finished just before an engine restart reads interrupted and cannot be landed #1657
Description
What happened
On dev (seen through PR #1632 at 458d1be73, whose recovery change does not touch this path), a task whose plan finished just before its engine restarted comes back interrupted with no way to finish it.
On 2026-09-28, in a git repo, on the engine road (plain codeaf, deepseek/deepseek-v4-flash): /task write a python script count.py that counts lines in every .txt file here, and a test for it; run the test. While the roster said Running 1, the workspace's codeaf engine daemon was killed. The surface reconnected to a new engine.
The task page then read:
interrupted · 43s · $0.0018
while its own body said done · ran 43s, and that count.py and four passing tests were written (they are on the task's branch). The page offers no enter retry (pressing Enter changes nothing). Asking the conversation to land it made the model call tasks with id: "2", resolve: "accept", which answered:
No task "2" in this project
Replication
Deterministic (no model). Not yet written. The ending is decided in reconcileSettledRun (below) for a plan root whose status is done at recovery time, so a session test can seed a checkpoint with an admitted run row plus a plan store whose root is done, open the conversation, and assert what the row says and what tasks answers for its id.
Field (real models). The steps above: any key the product accepts (OPENROUTER_API_KEY or the profile's key), a cheap model, about 2 minutes and under $0.01. What makes it fire: the plan must finish before the engine dies. Kill the daemon a few seconds after the worker reports its test passing.
Where
reconcileSettledRunininternal/session/task_run_recover.go. Its default case writesthe plan finished before the restart; inspect the saved working copy before landing its changesand leaves the row interrupted.- The retry affordance in
internal/tui3/taskretry.goonly offers a retry for a failed node without a run, so an interrupted plan run gets none. - In
internal/session/tools_tasks.go, plan rows are handled for reads, butresolveandcontinuefall through to the ordinary task lookup, which cannot find a plan-only run row. That's whereNo task "2"comes from.
The fix
A task whose plan finished before a restart is either offered as finished work to land (the same resolve / accept door a finished task has), or it says what to do next and that door works. The tasks tool must never answer "No task" for a task the page is showing.
Acceptance
End to end, through the engine road: kill the engine after the plan finishes, reopen, and the task can be landed through the page or tasks resolve. The receipt names the landed commit, and the spend shown before the kill is still shown after.
Activity
ZeroPoint95 commentedon Oct 5, 2026
Seen again on 2026-10-05 in the v0.7.1 happy-path pass, by a different road: an upgrade. In this case the task had already landed, and recovery rewrote a
donerow.v0.7.0, engine road, repository on branchwork), I handed off/task add Circle, Square and Triangle area functions….tasks.jsonlrecordedstatus: done,filesChanged: 3,artifactUri: git:workat 10:39:50, andgit logshows thetask: …commit holding exactly those three files.dev-20261005-f816387875e5, which saidreplaced the older engine on … (pid …, v0.7.0 …) — this build holds the workspace now.The task page header read
interrupted · 22swith a failure mark and aStop task…control, while its body still saiddone · ran 22s · … · landed on work: 3 files. The conversation itself had no landing card and nodone · …message: itstranscript.jsonlheld only the session line and usage lines. The v0.7.0 engine's last call, the main conversation's response to the landing, had returned headers 0.8 s after the landing and was still open when the engine was replaced. The "saved working copy" the outcome points at no longer existed, because the copy had been given back. Nothing was lost from the person's folder.It did not reproduce on a second v0.7.0 → dev upgrade, nor on four same-build restarts of the dev build: graceful
engine --stopright after the ledger said done, SIGTERM within 50 ms of it, with the main conversation mid-answer, and after closing the window first. So it needs the old engine to go while the conversation's record of the landing is still unwritten.Suggested addition to the fix: when the project ledger already has a
donerow with a landing for this task, recovery keeps it instead of appendinginterrupted.santoshkumarradha commentedon Oct 23, 2026
Fixed on dev by #1911 (b14ddcd). End-to-end verification completed through the real terminal and engine: finished worker/checker work survived restart, explicit acceptance landed the preserved files with an actual commit receipt, and the full task cost stayed unchanged. The live run recorded 24/24 calls on OpenRouter deepseek/deepseek-v4.1-flash; restart and acceptance added no calls or charges. Reproduction commands and mock-data proof are in the PR. All final-head GitHub checks passed.