Settle superseded shared-session streams so multi-agent viewers leave "Warping..."

[warp-agent-staging]

Summary

Enterprise users opening a factory-prompted Oz run via View conversation landed in the orchestrator stuck on a shimmering Warping... with no subagent progress, so the transcript looked hung (REMOTE-2538).

Root cause. Of the three shared-session agent events, only StreamInit carries a conversation id. A viewer therefore attributes every subsequent ClientActions and Finished event to a single current_response_id slot in BlocklistAIController. A multi-agent run interleaves the orchestrator's and its subagents' streams — reconstruct_response_events_from_conversations sorts every conversation's exchanges into one chronological event list, and deliberately omits the synthetic Finished for any exchange still in flight when the scrollback snapshot was built. So the orchestrator's stream is routinely replaced by a subagent's StreamInit before it is ever closed. Once replaced it is unreachable by construction: on_shared_finished only ever looks at current_response_id, so nothing can move that conversation out of ConversationStatus::InProgress. render_warping_indicator_for_latest_exchange gates on exactly that predicate, so the indicator shimmers for the rest of the session.

Fix. on_shared_init now closes out the superseded stream before installing the replacement, settling its conversation instead of leaving it in progress forever. The single live in-flight stream — the most recent one, which the live wire still closes — is untouched, so the deliberate "skip the synthetic Finished" behaviour keeps working for genuinely in-flight exchanges.

Relationship to REMOTE-1684. REMOTE-1684 ("Run can get stuck showing Warping after setup even though shared session loads") is the same stall family and its reporter's hypothesis — "a failure to enter the correct agent view … might be some race condition" — is consistent with this orphaning. This change plausibly fixes it, but that report is a single-run handoff with no captured event ordering, so I am not claiming it as fixed; it should be re-tested against this branch before being closed.

Relationship to the server-side half. warpdotdev/warp-server#13935 fixes an asymmetric ACL mirror that denied a viewer access to a multi-agent run's child conversations. That denial is a separate contributor to "no subagent progress" and remains reachable for conversations outside the direct-child relationship. The client already resolves a denied/unloadable conversation to a visible state rather than a hang, so no change was needed here for it:

• enter_agent_view_for_conversation shows an error toast when load_conversation_data yields None (app/src/terminal/view/agent_view.rs).
• hydrate_remote_child_transcript_in_place falls through to attach plus a conversation-ended tombstone on fetch failure (app/src/pane_group/child_agent/hydration.rs).
• The orchestration pill bar is driven by ambient-task state, not conversation reads, so a conversation ACL denial does not strand it.

Verification

New regression test test_shared_session_init_settles_superseded_conversation_instead_of_warping_forever (app/src/terminal/view/shared_session/view_impl_tests.rs) drives two interleaved shared-session streams through the real handle_shared_session_response_event path and asserts the superseded conversation's status — the exact predicate the Warping indicator renders on.

• Fails before the fix: assertion left == right failed … left: Some(InProgress) (the stuck state).
• Passes after the fix.
• cargo test -p warp --lib shared_session — 197 passed, 0 failed.
• cargo test -p warp --lib ai::blocklist — 719 passed, 0 failed.
• ./script/format --check — clean.
• cargo clippy -p warp --all-targets --tests -- -D warnings — clean.

The full cargo test -p warp --lib suite was not run to completion locally (it does not terminate in this sandbox); CI is the full-suite gate.

Visual proof: not captured — please confirm on review

This is a user-facing surface, so visual proof would normally be attached. It is outstanding, not satisfied. Reproducing the rendered state requires a live enterprise factory-prompted multi-agent Oz run plus an affected viewer account joining its shared session — the ticket records the same environment mismatch under Replication Steps ("no hands-on repro in this runner"), and this sandbox has neither a suitable run nor an account that can join one. The regression test asserts the precise conversation-status predicate the indicator gates on, but a human should still confirm the rendered behaviour: open View conversation on a factory-prompted multi-agent run and check the orchestrator settles out of Warping....

CHANGELOG-BUG-FIX: Fixed a shared session of a multi-agent run getting stuck on "Warping..." with no subagent progress.

Originating thread: https://warpdev.slack.com/archives/C0BDQDW8V5E/p1785971527475689

Conversation: https://staging.warp.dev/conversation/6d072844-0321-476c-bcde-e7aaf4e171de
Run: https://oz.staging.warp.dev/runs/019fd43d-d56a-7262-8b98-8d19ea68bf5d

This PR was generated with Oz.

[warp-agent-staging]

Overview

This PR settles a shared-session conversation when a later stream init supersedes it, preventing the confirmed stale InProgress state from keeping the orchestrator on Warping.... The code and deterministic regression coverage are sound, but the user-facing enterprise View conversation path remains unverified.

Concerns

❓ [QUESTION] This change has no screenshot or recording of an enterprise viewer opening View conversation for a factory-prompted multi-agent run and seeing the orchestrator transcript plus subagent progress without indefinite Warping. Please attach end-to-end visual proof for the ticket acceptance criteria; the existing environment explanation and unit test do not replace proof of the rendered flow.

Verdict

Checks: CI ✅ · format ✅ · Clippy ✅ · focused tests ✅ · visual proof ❌ (enterprise multi-agent View conversation flow not captured)
Found: 0 critical, 0 important, 0 suggestions, 1 human verification blocker

Request changes

Review run

https://oz.staging.warp.dev/runs/019fd49d-6525-7e5d-890a-4fb765b2ae58