Fix stranded action-result delivery race; document refuted hypotheses for #15659

[warp-agent-staging]

Description

Investigating https://github.com/warpdotdev/warp-server/issues/15659 ("search_conversation_history cancels when referencing other conversations via @Conversations / <convo:>"), I could not confirm the root cause of the reported Cancelled symptom, and I want to be explicit about that up front. This PR does not claim to fix #15659. It:

1. Documents, with evidence, why both the triage report's hypothesis and my own earlier hypothesis are refuted for the literal reported sequence (one prompt, no Stop, no second prompt).
2. Fixes a distinct, real, independently-evidenced defect I found while investigating (a stranded-result race, plus a follow-on race between that fix and an already-scheduled resume) — worth fixing on its own merits, but its symptom does not match "Cancelled".
3. Adds diagnostics so a future real occurrence is actionable.
4. Leaves an open lead for whoever picks this up next.

What's refuted, with evidence

FetchConversationResult::Cancelled is only ever produced by AIAgentActionType::cancelled_result(), called from cancel_running_async_action / cancel_all_running_async_actions_for_conversation / cancel_pending_action in app/src/ai/blocklist/action_model.rs and execute.rs. I enumerated every call site that can trigger this chain:

• app/src/ai/blocklist/controller.rs: stop_local_agent_conversation (Stop button), conversation deactivation (switching away while in progress), clear-buffer, delete/clear conversations, revert, shell exit, and send_query's own pre-cancel for a second query submitted to the same conversation (CancellationReason::FollowUpSubmitted{is_for_same_conversation:true}).
• app/src/terminal/view.rs: the same Stop/deactivation/clear-buffer paths.

Every one of these requires an explicit trigger beyond the single reported prompt. Neither ManuallyCancelled nor FollowUpSubmitted (the two hypotheses tested across this PR's revisions) fires in the literal reported sequence. So the customer-visible Cancelled state is not explained by the client's FetchConversation cancellation machinery in that sequence — both hypotheses are refuted.

I also explored, and reverted, a client-side wire-serialization change (mapping FetchConversationResult::Cancelled to an explicit Error instead of ConvertToAPITypeError::Ignore). It broadened the generic cancel wire contract without a proven delivery path — a mixed user-query/tool-result request is intercepted by the server as a cancel before ConversationSearchAgent can consume any explicit result — so it's reverted; crates/ai/src/agent/action_result/{mod.rs,convert.rs,convert_tests.rs} are back to their pre-PR state.

The stranding defect (fixed here)

Tracing send_follow_up_for_conversation (app/src/ai/blocklist/controller.rs), it defers sending a completed action's result when has_active_stream_for_conversation is still true for its conversation. That flag only clears once the triggering stream's AfterStreamFinished event has been fully processed (PendingResponseStreams::cleanup_stream + Conversation::cleanup_completed_response_stream). Receiving the stream's own Finished(Done) response event by itself (mark_request_completed) does not clear it — confirmed by reading both call sites in app/src/ai/agent/conversation.rs.

If an action resolves fast enough — e.g. FetchConversation served from an already in-memory conversation via load_conversation_by_server_token's fast path, which returns an already-Ready future — its FinishedAction can be processed in that window. Nothing ever retried the deferred send, so the result was stranded in finished_action_results indefinitely.

This is a real, independent, previously-unhandled defect. Its symptom is the affected inline block (e.g. a ConversationSearch subagent block) staying in its "still running" spinner state forever — not "Cancelled". So it likely is not what the customer saw, but it's worth fixing regardless.

Fix: flush_stranded_follow_up_for_conversation, called from the AfterStreamFinished normal-completion path once a stream's bookkeeping is actually cleared, retries delivery for any conversation left with finished-but-undelivered action results and nothing else pending/running.

Follow-on race, also fixed: the flush ran unconditionally on every AfterStreamFinished{cancellation: None}, including when the stream failed recoverably after dispatching client actions and scheduled an automatic resume for once it finishes (ResponseStream::pending_resume). If the flush fired in that case, its follow-up request and the scheduled resume could both fire, racing or colliding. flush_stranded_follow_up_for_conversation now reports whether it actually sent a request; the AfterStreamFinished handler skips arming the scheduled resume when it did, since that request already takes over resuming the conversation.

Recovery-budget inheritance, also fixed: ResponseStream::begin_recovery charges pending_resume with self.recovery.next_attempt() precisely so the retry/resume chain stays bounded by one shared counter (MAX_RECOVERY_ATTEMPTS). Suppressing that resume in favor of the flush was sending the replacement follow-up with RecoveryBudget::fresh(), silently resetting the counter on every server action → fast completion → post-action recoverable failure sequence. send_follow_up_for_conversation and flush_stranded_follow_up_for_conversation now take an explicit RecoveryBudget; the AfterStreamFinished handler reads pending_resume before flushing and passes its already-charged budget through when it replaces that resume.

Diagnostics: log lines at the two points that matter for a future occurrence: where send_follow_up_for_conversation defers (the moment a result would otherwise silently vanish), and where the flush recovers a stranded result.

Open lead for whoever picks this up next

I could not rule out (or confirm) that the server's own subagent/turn-limit handling — ConversationSearchAgent.Run's RunWithoutStoppingValidator, retry exhaustion, OnFatalError in warp-server/logic/ai/multi_agent/agents/conversation_search/agent.go — ever produces a Cancel-shaped outcome for the delegating tool call independent of any client action. That's a real code path I read but could not trace end-to-end without a live request trace. I don't have prod debugger/BQ access to the two request IDs from the original Slack thread; getting that access would very likely disambiguate this quickly.

Testing

• app/src/ai/blocklist/controller_tests.rs:
  • manual_cancel_of_pending_fetch_conversation_does_not_revive_conversation — a genuine ManuallyCancelled cancellation sends no follow-up and finalizes Cancelled.
  • collateral_cancel_of_pending_fetch_conversation_does_not_mark_conversation_cancelled — a FollowUpSubmitted{is_for_same_conversation:true} cancellation does not mark the conversation Cancelled.
  • stranded_action_result_is_flushed_once_triggering_stream_completes — drives the exact race (a Finished(Done) response event processed, then a fast action's FinishedAction, then the stream's own AfterStreamFinished), asserting the result is deferred (not dropped) and then delivered (not stranded).
  • flushed_stranded_result_suppresses_a_scheduled_resume_for_the_same_stream — drives a fast action's completion alongside a scheduled resume for the same stream, asserting exactly one follow-up request is sent, the scheduled resume is never armed, and the replacement request's stream inherited the resume's already-charged budget (attempts_used() == 1) rather than a fresh one.
• crates/ai/src/agent/action_result/mod_tests.rs: cancelled_fetch_conversation_does_not_unconditionally_trigger_a_follow_up_request (unrelated to the reverted conversion; guards should_trigger_request_upon_completion's unchanged behavior).
• New test-only seams: BlocklistAIActionModel::enqueue_pending_action_for_test, ResponseStream::emit_stream_finished_for_test, ResponseStream::set_pending_resume_for_test, ResponseStream::recovery_for_test, PendingResponseStreams::stream_for_test.

Validation commands run:

• cargo test -p ai agent::action_result — 6 passed, 0 failed.
• cargo test -p warp --lib controller::tests:: — 31 passed, 0 failed.
• cargo test -p warp --lib ai::blocklist:: — 783/783 passed on the final run; one earlier intermittent failure in secret_redaction::test::test_detect_secrets_no_regexes_configured, confirmed pre-existing and unrelated: it passes in isolation, passes on a clean checkout of this branch with my changes stashed, and flakes non-deterministically across repeated runs regardless of these changes (order/global-state dependent in the test binary, not caused by this diff).
• cargo fmt on all touched files — clean.
• cargo clippy -p ai --lib --all-features --tests -- -D warnings — clean.
• cargo clippy -p warp --lib -- -D warnings — clean.
• crates/ai/src/agent/action_result/{mod.rs,convert.rs,convert_tests.rs} verified byte-identical to pre-PR master via git diff --stat against the merge base.

Visual proof

This is a backend/protocol-level change (Rust conversion + stream/action bookkeeping logic) with no UI code touched, and I could not reproduce the customer's exact flow in this sandbox (no running Warp client or server backend, no authenticated account, no second real conversation to reference). Stated explicitly per the verification skill rather than substituting a code walkthrough for a capture; the regression tests above are the verification available here.

• I have manually tested my changes locally with ./script/run (not applicable — no UI change, and not achievable in this sandbox; see note above)

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-NONE

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.