feat(web): add the Agents panel (4/5) - #4663
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| activations: ReadonlyArray<OrchestrationV2SubagentActivation>; | ||
| }) { | ||
| const { agent } = props; | ||
| const detail = agent.progress?.trim() || agent.result?.trim() || agent.prompt.trim(); |
There was a problem hiding this comment.
🟡 Medium components/AgentsPanelV2.tsx:72
AgentCard selects agent.progress before agent.result, so a completed agent that still has residual progress text displays that stale in-progress string instead of its final result. The detail fallback chain at line 72 is agent.progress ?? agent.result ?? agent.prompt, which means any non-empty progress value wins even after the agent has settled. Consider checking the agent's status first and preferring agent.result for settled statuses (or using progress only for non-settled statuses).
- const detail = agent.progress?.trim() || agent.result?.trim() || agent.prompt.trim();
+ const settledStatuses: ReadonlyArray<OrchestrationV2Subagent["status"]> = ["idle", "failed"];
+ const isSettled = settledStatuses.includes(agent.status);
+ const detail =
+ (isSettled ? agent.result?.trim() || agent.progress?.trim() : agent.progress?.trim() || agent.result?.trim()) ||
+ agent.prompt.trim();🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @apps/web/src/components/AgentsPanelV2.tsx around line 72:
`AgentCard` selects `agent.progress` before `agent.result`, so a completed agent that still has residual `progress` text displays that stale in-progress string instead of its final `result`. The `detail` fallback chain at line 72 is `agent.progress ?? agent.result ?? agent.prompt`, which means any non-empty `progress` value wins even after the agent has settled. Consider checking the agent's status first and preferring `agent.result` for settled statuses (or using `progress` only for non-settled statuses).
c3a50f8 to
8c6a796
Compare
Surfaces the subagent data the previous PRs record. A new right-panel tab lists every subagent on the thread with its role, model, status, token usage, recent activity, and the runs it has been activated for. Grouping lives in client-runtime rather than the component so it stays testable: workflow coordinators own their phases, phase status derives from its members, and members orphaned by a missing coordinator fall back to the flat list rather than disappearing. A coordinator is an agent in its own right, so it renders as a card rather than a bare heading — it has a model, usage and activations, and before its members are spawned it is the only row on the thread. It is counted in the tallies for the same reason, but only while it has no members, since afterwards they represent the same work and counting both double-reports it. Without that, a thread running a workflow showed "0 active" with nothing listed and unexplained tokens in the header. Usage follows the same rule: the total keeps whatever the members did not account for. Dropping the coordinator outright erased the whole workflow whenever a provider reported workflow usage but omitted per-agent tokens, and the header read "Usage unavailable" for a workflow that had spent thousands. Read-only: this only renders what the projection already contains.
5187d5b to
cde2598
Compare
8c6a796 to
103b937
Compare
Fourth of five stacked PRs replacing #4551. Stacked on #4662 — review that first.
Surfaces the subagent data the previous PRs record. A new right-panel tab lists every subagent on the thread with its role, model, status, token usage, recent activity, and the runs it has been activated for. Read-only — it renders what the projection already contains.
Grouping lives in
client-runtimerather than the component so it stays testable: workflow coordinators own their phases, phase status derives from its members, and members orphaned by a missing coordinator fall back to the flat list rather than disappearing.Coordinators are agents too
A workflow coordinator has its own model, usage and activations, and before its members are spawned it is the only row on the thread. So it renders as a card rather than a bare heading, and it is counted in the tallies — but only while it has no members, since afterwards they represent the same work and counting both double-reports it.
Without that, a thread running a workflow showed
0 active · 0 waiting · 0 settledwith nothing listed, and unexplained tokens in the header.Token accounting
Same rule: the total keeps whatever the members did not account for. Dropping the coordinator outright erased the entire workflow whenever a provider reported workflow usage while omitting per-agent
tokens— the header then read "Usage unavailable" for a workflow that had spent thousands. Both fields are populated independently in the Claude adapter, so this is reachable, not theoretical.Testing
Typecheck and lint clean. Web 1,500 passing, client-runtime 486 passing.
Verified in a browser against a real Codex subagent run: the tab renders the agent with its role and model badges,
idlestatus, a real token count and run count, and an expandable "Activity and runs" section.Reviewed by an independent agent pass; the token-collapse bug and the missing coordinator card both came out of it and are fixed here.
Note
The workflow path itself (phases, coordinators) is Claude-only — no other adapter emits
kind: "workflow"— so that branch has unit coverage but has not been exercised against a live provider.