Retry exhaustion silently parks tasks in needs_input and makes the UI look stuck

[telemetrya2018-dotcom]

Summary

On Windows with Prime Agent 0.8.1, transient provider transport failures such as fetch failed exhaust the retry budget and silently end the active turn. Internally, the session changes to agent_status.taskState = needs_input, but the interactive UI does not make that terminal/waiting state clear. From the user's perspective, it is impossible to tell whether the agent is working, retrying, waiting for input, failed, or hung.

This report is about Prime Agent's recovery and state presentation. The original network/provider outage may be external, but a transient transport error should not leave a long-running task silently parked with ambiguous UI.

Observed behavior

A representative sequence was:

Error: fetch failed
Error: fetch failed
Error: fetch failed
Error: Retry failed after 3 attempts: fetch failed

After the final retry:

• the persisted assistant message has stopReason: "error";
• usage is input=0, output=0, totalTokens=0, with no response ID;
• agent_status.taskState changes to needs_input;
• no task work continues until the user sends another message;
• the UI does not clearly say Failed — waiting for user input or provide a direct Retry/Resume action.

In one captured case, the session emitted needs_input status heartbeats for about 46 minutes before the user asked whether it was stuck. After that new user message, work continued. The assistant then said it was not stuck, even though the recorded state shows that the prior turn had stopped and was waiting for input.

Sanitized log audit

A read-only structured audit parsed 101 JSONL files (33 top-level sessions and 68 nested child sessions). Quoted text was excluded; only assistant messages with stopReason="error" were counted.

• 5,809 assistant messages inspected
• 94 genuine structured errors across 24 session files
• 28 genuine fetch failed errors across 6 session files
• 9 separate fetch failed bursts
• affected models: openai-codex/gpt-5.6-sol and openai-codex/gpt-5.6-terra
• all 28 failures had zero tokens, zero cost, and no response ID
• retry cadence was roughly 45–58 seconds
• every completed burst transitioned to taskState: needs_input
• recovery usually required a new user message, after roughly 0.9–66 minutes
• two child sessions were never resumed

Two correlated failure windows affected multiple sessions at once:

• 2026-08-31 15:14–15:18 UTC: 2 sessions
• 2026-09-01 05:04–05:08 UTC: 4 sessions, including related parent/child sessions

No prompts, credentials, request payloads, tokens, account IDs, or private URLs are included in this report.

Steps to reproduce

A deterministic network fault injector was not used, but the observed path can be exercised as follows:

1. Start a long-running task in the interactive UI with automatic retries enabled.
2. Interrupt access to the active model endpoint long enough to exhaust the retry budget.
3. Wait for the final Retry failed after 3 attempts message.
4. Inspect the persisted session: the assistant turn ends with stopReason="error", followed by agent_status.taskState="needs_input".
5. Observe that the task does not continue after network recovery unless the user sends a new message.
6. Compare the internal state with what the UI communicates to the user.

Expected behavior

At minimum, after retry exhaustion the UI should show one authoritative state, for example:

FAILED — waiting for input
Last attempt: 3/3
Reason: transport failure
Work is preserved.
[Retry now] [Resume] [Cancel] [Copy diagnostics]

While retrying, show the attempt and next action (Retrying 2/3 in 4s). After recovery, show Recovered — continuing. Animated Thinking.../working indicators should only be visible while work is actually active.

For long-running/autonomous tasks, consider automatically resuming after a transient transport outage, or preserving a durable continuation action that the user can invoke without writing a new prompt.

Diagnostic improvements requested

• Preserve and expose the nested transport cause (DNS, TLS, timeout, connection reset, proxy, HTTP status) instead of only fetch failed.
• Include retry attempt, backoff, endpoint hostname/service, and correlation/request ID where available.
• Keep secrets, headers, and request bodies redacted.
• Group duplicate errors in the main view (fetch failed ×4) while preserving each attempt in detailed logs.
• Warn when there has been no progress for an unusual period.
• Ensure status narration cannot claim the process is active when the authoritative task state is needs_input.

Environment

• Prime Agent: 0.8.1
• OS: Windows
• Mode: interactive UI with background daemon/RLM sessions

[telemetrya2018-dotcom]

Additional concrete reproduction from a different provider path (hermes-local -> zai/glm-5.3-flash) on Windows / Prime Agent 0.8.1:

• User prompt recorded at 2026-09-01 06:16:31 UTC.
• Attempt 0 ended at 06:35:41 with HTTP 500: The server had an error while processing your request.
• Retry 1 ended at 06:36:30 with the same HTTP 500.
• Retry 2 ended at 06:37:31 with Request timed out or interrupted.
• Retry 3 ended at 06:38:26 with HTTP 500.
• The UI then showed Retry failed after 3 attempts.
• Persisted agent_status.taskState remained needs_input through at least 07:21:56 UTC; it was not still working.

The first failed attempt had already streamed about 2.7k characters of progress-like text, but the persisted assistant message still had stopReason="error" and zero recorded usage. This is especially ambiguous: the transcript looks as though substantial work completed, while the authoritative turn state says the request failed and stopped.

Also, the timeout message linked to Anthropic API documentation even though the selected model shown in the UI was Hermes · Z.AI / GLM · glm-5.3-flash. Provider-specific remediation is therefore misleading.

Requested UI behavior: explicitly label partial output from a failed turn as unverified/incomplete, show the actual selected provider chain, and end in a visible FAILED — waiting for input state rather than leaving the user to ask whether the task launched or hung.