allod/tools
2
0
Fork 0
Code Issues 13 Pull requests Projects Releases Packages Wiki Activity Actions

Paginate forge list and resolver commands #89

New issue
Open
opened 2026-07-07 21:41:19 +01:00 by vnprc-agent · 0 comments
vnprc-agent commented 2026-07-07 21:41:19 +01:00
Contributor
Copy link

User story: So that I can rely on forge as repositories grow, list and resolver commands must paginate enough results to find the requested issue, PR, label, or milestone instead of silently missing page-two data.

Part of the "Forge / workspace CLI tooling" arc.

Problem

Several forge list and lookup paths use fixed API limits or a single page:

  • pr list uses limit=50.
  • pr find-by-head and branch-name PR resolution use limit=50 and can miss matching branches past the first page.
  • label and milestone resolution use limit=100.
  • issue and label list expose --limit, but they still perform one request.

This is fine for the current small repos, but it will silently drop data as the issue and PR backlog grows.

Desired Behavior

Add pagination helpers and use them anywhere correctness depends on seeing the full result set.

Minimum scope:

  • PR list and branch/head lookup.
  • Issue list when --limit exceeds one API page, or when filtering/searching needs more than the first page.
  • Label and milestone list/resolution.

Preserve the existing -L / --limit UX where it already exists, but fetch enough pages to honor it. For resolver paths, fetch all pages needed to disambiguate or fail clearly.

Validation

Fixture tests should prove a match on page 2 is found, a missing target remains missing after all pages, and output still respects the user-facing limit.

**User story:** So that I can rely on `forge` as repositories grow, list and resolver commands must paginate enough results to find the requested issue, PR, label, or milestone instead of silently missing page-two data. _Part of the "Forge / workspace CLI tooling" arc._ --- ## Problem Several `forge` list and lookup paths use fixed API limits or a single page: - `pr list` uses `limit=50`. - `pr find-by-head` and branch-name PR resolution use `limit=50` and can miss matching branches past the first page. - label and milestone resolution use `limit=100`. - issue and label list expose `--limit`, but they still perform one request. This is fine for the current small repos, but it will silently drop data as the issue and PR backlog grows. ## Desired Behavior Add pagination helpers and use them anywhere correctness depends on seeing the full result set. Minimum scope: - PR list and branch/head lookup. - Issue list when `--limit` exceeds one API page, or when filtering/searching needs more than the first page. - Label and milestone list/resolution. Preserve the existing `-L` / `--limit` UX where it already exists, but fetch enough pages to honor it. For resolver paths, fetch all pages needed to disambiguate or fail clearly. ## Validation Fixture tests should prove a match on page 2 is found, a missing target remains missing after all pages, and output still respects the user-facing limit.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allod/tools#89
No description provided.