Close agent chat/terminal tabs when their agent is destroyed externally#148
Open
gnguralnick wants to merge 3 commits into
Open
Close agent chat/terminal tabs when their agent is destroyed externally#148gnguralnick wants to merge 3 commits into
gnguralnick wants to merge 3 commits into
Conversation
When an agent was destroyed outside the system_interface UI (e.g. from a terminal), the backend broadcast an updated agent list but the frontend only used that event to open the initial chat tab -- the destroyed agent's chat and terminal tabs stayed open. Reconcile open agent-bound tabs against each agents_updated event and close any whose backing agent was seen alive earlier this session and has since disappeared. An ever-seen gate prevents tearing down tabs for agents that simply haven't loaded yet (empty list right after connect, or restored-layout tabs before the first update). Co-authored-by: Sculptor <sculptor@imbue.com>
Problem: The rule for recognizing an agent-terminal iframe URL
(url.startsWith(<terminal url>) && url.includes("arg=agent")) was
duplicated in DockviewWorkspace.ts -- the newly added getPanelBackingAgentId
carried one copy and createComponent's iframe case already had an identical
one. The two recognition sites could drift apart on any future change to the
terminal-URL shape.
Fix: Extract the predicate into a single exported pure helper,
isAgentTerminalUrl(url, terminalUrlPrefix), placed beside the existing
buildAgentTerminalUrl URL constructor, and use it at both sites. The prefix is
passed in so the helper stays pure and unit-testable, matching how
getPanelBackingAgentId already threads the prefix through.
Co-authored-by: Sculptor <sculptor@imbue.com>
…to gabriel/destroyed-agent-tabs
Contributor
|
I'm a little skeptical of the UX here -- it would be very confusing to a user if their chat just disappeared It seems better to keep the chat open (if it was already open), but simply have some sort of "this agent was destroyed" overlay, and then they can close it? That would properly communicate to them what happened |
Contributor
Author
|
sounds good. i can switch it to that! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
In the system_interface dockview UI, destroying an agent from outside the UI (e.g. from a terminal) left that agent's chat and terminal tabs open. They now close automatically.
Why it happened
The backend already broadcasts an updated agent list on external destruction (
_handle_agent_destroyed->broadcast_agents_updated). The frontend'sagents_updatedhandler inDockviewWorkspace.tsused that event only to open the initial chat tab; it never reconciled already-open tabs against the live agent set.The change
computePanelsToCloseForRemovedAgents(...)(pure, exported): given the open panels plus the live and ever-seen agent id sets, returns which tabs to close.agents_updatedlistener now closes those tabs before its existing initial-tab logic.The in-UI destroy button path already removes the panel directly, so the reconciliation is a no-op there (no double-removal).
Tests
Added
DockviewWorkspace.test.ts(6 cases): destroyed agents' chat and terminal tabs close; live agents, not-yet-seen agents, and non-agent tabs are untouched; mixed layouts close only the dead agent's tabs.npm run lint-> cleannpm run test-> 89 passed, 0 failed