Skip to content

feat(bugs): let bugs list --status accept multiple values#276

Merged
sachiniyer merged 3 commits intomainfrom
siyer/bugs-list-multi-status
May 6, 2026
Merged

feat(bugs): let bugs list --status accept multiple values#276
sachiniyer merged 3 commits intomainfrom
siyer/bugs-list-multi-status

Conversation

@sachiniyer
Copy link
Copy Markdown
Contributor

@sachiniyer sachiniyer commented May 5, 2026

Summary

  • Triage transcripts often want "open + resolved" or "everything" in a single shot. The single-valued --status forced agents to run the command N times and concatenate with jq.
  • Make --status a Vec<BugReviewState> accepting either repeated flags (--status resolved --status dismissed) or comma-separated values (--status pending,resolved). Default stays pending — existing invocations are unaffected.
  • The bugs API only accepts one status per request, so multi-status fans out to one paginated fetch_all_bugs call per status and concatenates in the order the user asked for. Multi-status forces the client-side filter+paginate path so result ordering and counts stay consistent.

Testing

Automated, run locally and passing:

  • cargo test — full suite green. 3 new clap-parse tests in src/lib.rs:
    • bugs_list_status_default_is_pending
    • bugs_list_status_comma_separated_parses
    • bugs_list_status_repeated_flag_parses
  • All pre-existing bugs list tests still pass (default still parses to [Pending], so silent-output and pagination invariants are preserved).
  • cargo clippy -- -D warnings — clean
  • cargo fmt --check — clean
  • cargo xtask check — clean (HELP.md regenerated in 20adde8)

Manual end-to-end against live API (repo: usedetail/detail — pending=305, resolved=674, dismissed=109; total=1088):

  • --status pending,resolved --limit 100total=979 ✅ matches 305 + 674
  • --status pending --status resolved --limit 100total=979 ✅ comma-separated and repeated-flag forms produce identical results
  • --status pending,resolved,dismissed --limit 100total=1088 ✅ matches the full union
  • Bare bugs list usedetail/detail --format jsontotal=305, total_pages=7 ✅ default-pending path unchanged, hits client.list_bugs directly (no fan-out)

🤖 Generated with Claude Code

@sachiniyer sachiniyer temporarily deployed to integration-tests May 5, 2026 18:21 — with GitHub Actions Inactive
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 94b8717951

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/commands/bugs.rs Outdated
Comment on lines +308 to +310
for status in statuses {
let bugs = fetch_all_bugs(client, repo_id, *status, scan_id).await?;
combined.extend(bugs);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Deduplicate repeated --status values before fetching

fetch_all_bugs_multi_status iterates statuses verbatim and appends each result set, so passing the same state more than once (for example --status resolved --status resolved or --status pending,pending) returns duplicate bug rows and inflated totals/pages instead of a true combined set. Since this command advertises multi-status combination behavior, repeated inputs should be normalized (deduped while preserving first-seen order) before issuing API calls.

Useful? React with 👍 / 👎.

@sachiniyer sachiniyer temporarily deployed to integration-tests May 6, 2026 20:34 — with GitHub Actions Inactive
@sachiniyer sachiniyer force-pushed the siyer/bugs-list-multi-status branch from 20adde8 to 4e38804 Compare May 6, 2026 22:28
@sachiniyer sachiniyer temporarily deployed to integration-tests May 6, 2026 22:28 — with GitHub Actions Inactive
@sachiniyer sachiniyer force-pushed the siyer/bugs-list-multi-status branch from 4e38804 to 9b19d2a Compare May 6, 2026 22:41
@sachiniyer sachiniyer temporarily deployed to integration-tests May 6, 2026 22:41 — with GitHub Actions Inactive
@sachiniyer sachiniyer changed the base branch from main to graphite-base/276 May 6, 2026 22:43
@sachiniyer sachiniyer changed the base branch from graphite-base/276 to siyer/bugs-list-since-until May 6, 2026 22:43
Copy link
Copy Markdown
Contributor Author

sachiniyer commented May 6, 2026

@sachiniyer sachiniyer temporarily deployed to integration-tests May 6, 2026 23:01 — with GitHub Actions Inactive
Base automatically changed from siyer/bugs-list-since-until to main May 6, 2026 23:02
sachiniyer and others added 3 commits May 6, 2026 16:03
Triage commonly wants "open + resolved" or "everything" in one go.
The single-valued `--status` forced agents to run the command N
times and merge with jq. Make it `Vec<BugReviewState>` accepting
either repeated `--status` flags or comma-separated values
(`--status pending,resolved`); default stays `pending` so existing
invocations are unaffected.

The bugs API only takes one status per request, so multi-status
fans out to one paginated `fetch_all_bugs` call per status and
concatenates in the order the user asked for. Multi-status forces
the client-side filter+paginate path so result ordering and
counts stay consistent.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`fetch_all_bugs_multi_status` iterated the input statuses verbatim, so
`--status pending,pending` (or `--status pending --status pending`)
issued the same paginated API call twice and concatenated the results.
Net effect: every bug appeared twice in the combined output, doubling
the reported total and inflating page counts.

Normalize the statuses with `dedupe_statuses` (preserves first-seen
order) before fanning out. Live verification against `usedetail/detail`:

  --status pending             → 302 items, 302 unique IDs
  --status pending,pending     → 302 items, 302 unique IDs   (was 604)
  --status pending --status pending → same                    (was 604)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@sachiniyer sachiniyer force-pushed the siyer/bugs-list-multi-status branch from a75903d to e4515dc Compare May 6, 2026 23:03
@sachiniyer sachiniyer temporarily deployed to integration-tests May 6, 2026 23:03 — with GitHub Actions Inactive
@sachiniyer sachiniyer enabled auto-merge (squash) May 6, 2026 23:03
@sachiniyer sachiniyer merged commit cc67420 into main May 6, 2026
13 checks passed
@sachiniyer sachiniyer deleted the siyer/bugs-list-multi-status branch May 6, 2026 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant