fix: correct multi-status pagination in `bugs list`

Merged
DE
5mo ago
+237-14

Summary

Fixes #300.

fetch_page_multi_status applied a shared offset to every per-status API call, then truncated the concatenated results to limit. This made bugs from later statuses permanently unreachable on page 2+ because their per-status offset skipped items that were only truncated away (never shown) on page 1.

Before: each status queried with (limit, offset) → concatenated → truncated to limit.
After: each status queried with (offset + limit, 0) → concatenated → drain first offset items → truncate to limit.

This ensures the pagination window is applied over the combined result set rather than per-status, so every bug is reachable regardless of status ordering.

Review & Testing Checklist for Human

  • Verify with a repo that has bugs in multiple statuses (e.g. 50+ pending, 40+ resolved): run detail bugs list --status pending --status resolved --limit 50 --page 1 and --page 2 and confirm all bugs appear across pages with no gaps
  • Check that single-status bugs list pagination is unaffected (this code path is only used for multi-status queries)
  • Confirm --page 1 still returns the correct first page of results

Notes

The fix uses saturating_add for offset + limit to avoid overflow on extreme page/limit values.

Link to Devin session: https://app.devin.ai/sessions/7a885031946844ed914b5740feff94fa
Requested by: @sachiniyer

Open in Devin Review

Summary by cubic

Fixes multi-status pagination in bugs list so pages are built over the combined results, making bugs from later statuses reachable on page 2+.

  • Bug Fixes
    • Fetch each status from offset 0 up to offset + limit, paginating in chunks to respect the API limit; merge, drop the first offset, then take limit.
    • Use saturating_add to prevent overflow on large page/limit values.