Proposal: stage-aware timeout recovery from durable Tool Results

[liugddx]

Background

In Maka Desktop, an Agent was asked to inspect a GitHub pull request:

#4066

The Agent successfully called WebFetch and received the PR content, but did
not produce the final assistant response. The UI eventually reported only a
generic request timeout.

This issue is about a Turn timing out after a successful Tool Result, during
the model continuation/final-response stage. It is not the same as #4066,
which concerns a persisted transcript tail not being delivered to the active
Desktop replica. It is also distinct from #3884, where a completed Plan tool
result intentionally stops the provider loop before the final response.

Observed behavior

The observable sequence is:

user request
  -> WebFetch call
  -> GitHub response succeeds
  -> Tool Result is accepted/persisted
  -> model continuation or final response delivery waits
  -> generic request timeout

The user cannot tell whether GitHub failed, whether the Tool Result was saved,
whether retrying will execute the tool again, or how to continue from the
existing result.

The current Runtime already has durable RuntimeEvents and a fail-closed
continuation planner, but Desktop safe resume is feature-flagged and the
renderer only exposes it for app_restarted. Timeout errors are not classified
as a post-tool continuation phase. The stream watchdog currently reports only
connect or idle, and the provider retry guard refuses an idle retry after
observable tool activity.

Expected behavior

When the Tool Result is durable and the missing work is only model continuation:

1. Preserve the Tool Result and all prior durable events.
2. Classify the failure phase explicitly, for example:
   • model_initial
   • tool_execution
   • model_after_tool
   • assistant_persistence
   • transcript_delivery
3. Tell the user that the tool succeeded but the model continuation timed out.
4. Offer Continue generating from the saved Tool Result without re-running
   the successful tool.
5. Permit one bounded automatic continuation retry for read-only tools such as
   Read, Glob, Grep, and WebFetch.
6. Do not blindly repeat Write, Edit, Shell, or external side-effect tools;
   park when the side-effect state is uncertain.

Implementation scope

• Add a deterministic Runtime regression test for successful WebFetch (or a
  read-only fixture) followed by a provider continuation timeout.
• Add durable, structured timeout-phase metadata to the Turn/model-call trace.
• Reuse turn.resume.query/start for a planner-approved continuation and expose
  it for eligible timeout Turns in Desktop.
• Verify that the continuation replay consumes the existing Tool Result and
  does not dispatch the tool again.
• Add separate coverage for the case where the final assistant message is
  durable but transcript delivery is stale; that case belongs to fix(desktop): deliver mid-session tail append after loading history #4066-style
  transcript synchronization, not this recovery path.

Acceptance criteria

• Tool success followed by model continuation timeout is reported with the
  correct phase, not as an undifferentiated request timeout.
• Durable Tool Results remain inspectable after the Turn fails.
• An eligible Turn has a Continue generating action.
• Continuing uses the existing durable Tool Result and never re-executes a
  successful side-effecting tool.
• Read-only tools support at most one bounded automatic continuation retry.
• Unsafe or indeterminate side effects fail closed and expose a manual
  recovery/inspection path.
• Runtime trace/ledger evidence distinguishes tool success, provider timeout,
  and transcript delivery failure.
• Regression tests cover tool success, post-tool timeout, recovery success,
  and assistant-persisted/transcript-undelivered independently.

Environment

• Surface: Maka Desktop
• Repository: apache/maka
• Reproduction URL: fix(desktop): deliver mid-session tail append after loading history #4066
• OS/model/provider/version: to be filled from the affected Turn's diagnostics

[liugddx]

Initial implementation is available in PR #4075. It adds a guarded Desktop continuation affordance only when the failed Turn has a timeout and at least one completed Tool Result; incomplete or errored tools remain gated. The existing fail-closed urn.resume.query/start planner remains authoritative, and the rollout flag is unchanged. Runtime timeout-phase persistence and read-only automatic retry remain follow-up work in this Issue.