Retry/Continue can run while session runtime is reported idle

[ashwin-pc]

Summary

When an incomplete or aborted response is resumed with the Continue/Retry action, the agent can be actively generating messages and executing tools while pi-web reports the session as idle.

Consequences:

• the session tab/drawer has no running spinner;
• the composer running status and Stop action disappear;
• GET /api/sessions reports runtime.isRunning: false and runtime.isStreaming: false for the active session.

Reproduction

1. Produce an aborted or otherwise incomplete assistant response.
2. Use the response card's Continue (or Retry) action, which calls POST /api/session/retry.
3. Let the resumed turn execute one or more tools.
4. While tools are visibly running and transcript entries are still being appended, inspect the session tab/composer or GET /api/sessions.

Actual: the session is shown as idle and the API runtime has isRunning: false.

Expected: the resumed session remains running for the full retry/continuation, including tool execution, and the Stop action remains available.

Root cause

The compatibility fallback in retrySessionFromFailure() calls the low-level agent directly:

await internal.agent.continue();
while (typeof internal._handlePostAgentRun === "function" && await internal._handlePostAgentRun()) {
  await internal.agent.continue();
}

This bypasses AgentSession._runAgentPrompt(), which normally sets _isAgentRunActive = true and later emits the settled lifecycle. AgentSession.isStreaming therefore stays false for the entire resumed run.

runtimeForPath() derives isRunning only from live.isStreaming, retrying, or compacting. Although /api/session/retry acquires a work lease, runtimeForPath() does not consider entry.workLeases. Every pi event consequently broadcasts a false session_runtime_changed, immediately overwriting the frontend's optimistic agent_start state.

Relevant locations:

• server.ts: retrySessionFromFailure() fallback
• server.ts: runtimeForPath()
• server.ts: registerLiveSession() runtime broadcast
• src/realtime/realtime.ts: session_runtime_changed handling

Suggested direction

Prefer a public AgentSession continuation/retry API that participates in the normal run lifecycle. As a compatibility fallback, ensure the whole low-level continuation is represented as active runtime.

If work leases are incorporated into runtimeForPath(), the finalizer must release the lease before broadcasting the terminal runtime; otherwise the final broadcast will remain running. Concurrency guards should also reject a second retry while a work lease/continuation is active.

Acceptance criteria

• A retried/continued response reports isRunning: true from start through all model and tool activity.
• The session tab/drawer spinner and composer running/Stop UI stay visible throughout.
• Exactly one terminal runtime update reports the session idle after completion or abort.
• A second retry cannot start while the first retry is active.
• Regression coverage includes a retry with a long-running tool, not only model streaming.

[ashwin-pc]

Real-world confirmation (2026-07-29)

I reproduced the same state split after an aborted, incomplete response:

1. The response card offered Continue.
2. Clicking it left the button at Continuing… and surfaced:

   Agent is already processing. Wait for completion before continuing.

3. Submitting a normal follow-up then surfaced:

   Agent is already processing a prompt. Use steer() or followUp() to queue messages, or wait for completion.

4. At the same time, pi-web reported the loaded session as completely idle:
   • GET /api/state?sessionId=…: isStreaming: false, isRetrying: false
   • runtime.isRunning: false, runtime.isStreaming: false
   • no steering or follow-up messages queued
   • the session list/orchestration status also showed idle

This is especially confusing because the low-level agent's activeRun guard and pi-web's public runtime state disagree. The user cannot reliably stop, continue, or submit a new prompt.

Fix validation plan

1. Add a deterministic long-running retry fixture

The current mock retry completes after roughly 150 ms, which is too short to inspect intermediate state reliably. Extend the mock so a manual retry/continuation can pause at a controllable gate for both:

• model streaming; and
• tool execution after model streaming has ended.

The test must not depend on arbitrary sleeps. Expose a test-only release endpoint or equivalent deterministic promise gate.

2. Extend tests/e2e/retry-errors.spec.ts

For both Retry after a terminal model failure and Continue after an incomplete tool-result turn:

1. Create the failed/incomplete response and reload the page, preserving the existing coverage.
2. Click Retry or Continue and hold the mock continuation at the gate.
3. While held, assert all public representations agree that the session is running:
   • GET /api/state?sessionId=… has runtime.isRunning === true;
   • the matching item from GET /api/sessions has runtime.isRunning === true;
   • the session tab/drawer shows its running indicator;
   • the composer shows running state and the Stop action remains available;
   • a page reload or second client still reconstructs the session as running.
4. Keep the continuation held through a mock long-running tool and repeat the assertions. This catches the original failure mode where model streaming may be over but post-run/tool work is still active.
5. Attempt a second POST /api/session/retry while the first is held. Assert a deterministic 409 (or the selected conflict response) and verify that no second agent run starts.
6. Submit a normal composer message while held. It must follow the UI's configured streaming behavior (queue/steer/follow-up or remain disabled), not invoke a plain prompt and expose the low-level Agent is already processing exception.
7. Release the gate and assert:
   • the recovered assistant response appears once;
   • the running UI disappears;
   • /api/state and /api/sessions both become idle;
   • exactly one terminal session_runtime_changed transition reports isRunning: false after the work lease/run is finished.
8. Submit a fresh prompt after settlement and assert it succeeds. This verifies that the low-level activeRun was cleared, not merely hidden from pi-web.

3. Cover abort and error cleanup

Run the same gated continuation in two additional cases:

• click Stop while the retry is in model streaming;
• click Stop while the retry is in the long-running tool/post-run phase.

For each case, assert that the abort reaches the actual low-level run, all runtime surfaces settle to idle, the button does not remain stuck at Continuing…, and a subsequent prompt or retry can start. Also inject a continuation error and make the same cleanup assertions.

4. Exercise the real SDK fallback manually

The mock implements its own retryFromFailure, so a passing mock-only test does not prove that the compatibility path around internal.agent.continue() is fixed.

With the SDK version that uses that fallback:

1. Start pi-web and produce an incomplete/aborted response that ends in a tool result.
2. Make the continued turn run a tool for at least 5–10 seconds.
3. Click Continue.
4. During model generation and during the tool, inspect /api/state?sessionId=… and /api/sessions; both must remain running, and Stop must remain visible.
5. Reload during the tool and verify running state is restored.
6. Stop the run, verify both APIs become idle, then send a new prompt successfully.
7. Repeat once without stopping and verify normal completion has the same clean terminal state.

5. Required checks

npm run typecheck
npm run build
npm test

The fix is validated only if the automated gate-based regression passes and the real SDK fallback is manually exercised. A 150 ms mock-only happy-path test is insufficient for this race/state-synchronization bug.