fix: mark Lead agents in handle_status so CLI filters them from coworker list#2332
Merged
fix: mark Lead agents in handle_status so CLI filters them from coworker list#2332
Conversation
…ker list The daemon's handle_status emits each running agent into the coworkers JSON array but never sets is_channel_lead. The CLI deserializes the response into Response::Coworkers (CoworkerInfo with #[serde(default)]), so is_channel_lead silently defaults to false for project leads and topic-channel leads. The display formatter then fails to filter them out, and `midtown status` shows leads alongside actual workers. Discovered via dogfood: `midtown status` listed `midtown` (project lead) and `ops` (channel lead) in the Coworkers section. Failing reproduction test added in rpc_tests.rs.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2332 +/- ##
==========================================
+ Coverage 63.70% 63.95% +0.25%
==========================================
Files 100 100
Lines 38582 38592 +10
==========================================
+ Hits 24578 24683 +105
+ Misses 14004 13909 -95
🚀 New features to boost your workflow:
|
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.
Summary
midtown statuswas listing the project lead and topic-channel leads in the Coworkers section alongside actual workers. Discovered while dogfooding the lead → task → worker → PR → merge flow.Root cause
handle_statusinsrc/daemon_v2/rpc/handlers.rsemitscoworker_type: "lead"(a string label) for each running agent, but the CLI'sResponse::Coworkersdeserializer (CoworkerInfo) readsis_channel_lead(a bool flag) — different field names. With#[serde(default)]onis_channel_lead, the flag silently defaulted tofalsefor every agent, so the display formatter's!cw.is_channel_leadfilter never excluded leads.The companion
handle_agent_listdoes the right thing because it emits thekindfield that the CLI also recognizes — that's whymidtown agent listcorrectly classifies agents whilemidtown statusdoesn't.Fix
One field added to the
handle_statuscoworker JSON:Both project leads (
midtown-project-lead) and topic-channel leads (midtown-channel-lead) areAgentKind::Lead, so a single check covers both.Test plan
handle_status_marks_lead_coworkers_as_channel_leadsinsrc/daemon_v2/rpc/rpc_tests.rs— builds a Projections with one running worker, one running project lead, and one running topic-channel lead; asserts the worker hasis_channel_lead=falseand both leads haveis_channel_lead=true. Confirmed failing on the unfixed code (`Null` in place of the bool), passing after the fix.🌃 Co-built with Midtown