[Bug] Daemon reconnect leaves an active prompt blocked and the session unavailable (0.7.3)

[Atroci]

Summary

During an active Prime Agent session embedded in Orca, the daemon connection dropped while a prompt was being handled. The TUI entered its reconnect loop, but a subsequent prompt could not be sent and remained waiting. At the time of capture, the session had not recovered in the visible client.

The first fetch failed line below may be an unrelated provider/tool failure; the report focuses on the daemon disconnect and prompt handling that followed.

Environment

• Prime Agent 0.7.3
• Orca 1.4.183
• Fedora Linux 44, x86_64
• Node.js 24.15.0
• Prime Agent is launched as a supported/resumable Orca agent

No API keys, tokens, prompts, transcript bodies, session IDs, socket paths, or local paths are included.

Sanitized observed output

Error: fetch failed
Daemon connection lost; reconnecting…
Error: Cannot send daemon command "prompt" because the Prime Agent daemon is not connected.
Waiting

The client showed the reconnecting state and then rejected the prompt command because the daemon was still unavailable. The entered prompt was not visibly acknowledged as queued, rejected before consumption, or safely recoverable.

Expected behavior

After a supervisor/daemon interruption, the client should either:

1. reattach the existing worker/session and continue accepting input; or
2. fail explicitly with a safe, actionable resume path using the persisted session file.

A prompt submitted during reconnect should have an unambiguous exactly-once outcome: it must be durably queued, or rejected before being consumed with a clear retry instruction. It should not remain in an indefinite waiting state or be silently lost/duplicated.

Reproduction status

This is a real observed incident, but I do not yet have a deterministic provider-backed reproduction. A disposable smoke test without credentials could not reach a model call (No API key found for the selected model), so I am not claiming that test reproduced the daemon failure.

A useful deterministic test would keep a worker alive, interrupt or replace only the supervisor, submit a prompt during the reconnect window, and then verify both the client state and the JSONL transcript after recovery. The test should cover a prompt sent before the interruption, during reconnect, and after reattachment, and should verify that no uncertain model/tool side effect is replayed.

Related records (adjacent, not claimed as exact duplicates)

• Discussion #1641 — v0.8.0 supervisor replacement can leave active session IDs unknown after failed worker adoption.
• Discussion #1650 — a saved session becomes unopenable after failed worker recovery.
• Discussion #1566 — SIGTERM during an in-flight tool call leaves a reattached session frozen.
• Issue #1371 — prompt aborted and silently lost at daemon stop/restart (closed during the move to Discussions).

This report is intentionally limited to the daemon reconnect/prompt boundary. Please merge it with an existing record if maintainers consider the recovery path the same bug, or advise which sanitized diagnostics are most useful on the next occurrence.

[Atroci]

Update: the primary failure is the interactive Python/IPython timeout, not the daemon reconnect itself. Existing Discussion #1544 is the canonical report for interactive tool calls with no automatic timeout; I added the Orca-specific evidence and v0.7.3 source links there. This discussion should be treated as downstream integration context rather than a separate timeout report.