Moving the last pane out of a tab logs two report_error! events

Open

Describe the bug

PaneGroup::remove_pane_for_move (app/src/pane_group/mod.rs) emits two report_error! events whenever the pane being moved is the last pane in its tab:

"[PaneGroup] Unable to locate a panel to activate after close" (mod.rs around line 4681). focus_next_terminal_pane_and_activate_session runs for the removed pane, and prev_pane_id finds no other pane to focus.
"Pane not found" (mod.rs around line 4388). self.panes.remove(pane_id) returns false because the pane tree can't remove its only root leaf.

Both are expected on this path, since the tab is about to close, but they are reported at error level. The group also emits Event::Exited before the pane is removed from the tree.

To reproduce

Run any flow that calls remove_pane_for_move on a tab's only pane. The existing child-agent "re-adopt" path (try_re_adopt_split_off_child_agent_tab in app/src/workspace/view.rs) does this.
Watch the error reporter, or run a test that does the move with RUST_LOG=warn.
Both messages above are logged for each move.

I found this while working on a tab-merge prototype (#16610), where it happens once per merged tab. I saw it in test logs and have not checked how much volume it produces in the error reporter.

Expected behavior

Moving the last pane out of a tab doesn't log error-level events. For example, handle the single-pane case explicitly before calling into focus handling and tree removal.

Operating system (OS)

macOS

Operating system and version

macOS 27.0.1

Shell Version

zsh

Activity

warp-for-oss[bot]8d ago

@nickvirden

Here's what I found while triaging this issue:

This looks actionable from the provided repro and code inspection. No additional reporter detail is needed for initial routing.

I've flagged this for the factory auto-implement queue.

Maintainer details

I concluded that moving the only pane out of a tab currently triggers expected single-pane cleanup paths that are reported as error-level events..

Triage summary

This is a client-side pane/tab lifecycle bug. The report is actionable: moving a tab's only pane through PaneGroup::remove_pane_for_move can hit two expected single-pane states that are currently reported as errors.

Evidence

app/src/pane_group/mod.rs calls focus_next_terminal_pane_and_activate_session before the single-pane Event::Exited branch in remove_pane_for_move, so a focused only pane has no previous pane to activate.
The same function then calls self.panes.remove(*pane_id); in app/src/pane_group/tree.rs, PaneNode::Leaf::remove returns false, so removing the root-only pane reports Pane not found.
app/src/workspace/view.rs has a concrete caller in try_re_adopt_split_off_child_agent_tab, which moves a lone split-off child-agent pane back to its source tab during close handling.

Likely fix direction

Handle the single-pane move case explicitly before focus handoff and tree removal, preserving the moved pane content while avoiding error-level reports for the expected tab-exit path.

Duplicate check

I scanned all open non-PR issues and recently closed issues from the last 7 days. I found one open issue sharing the same log strings, #14802, but it describes a different user-facing conversation-history-loss symptom and is not enough to mark this issue as a duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.