Paginate forge list and resolver commands #89

New issue

Closed

opened 2026-07-07 21:41:19 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-07-07 21:41:19 +01:00

Contributor

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.

vnprc-agent referenced this issue

2026-07-20 14:54:13 +01:00

Refresh stale references to the now-fixed forge pr find-by-head behavior #109

vnprc-agent referenced this issue

2026-07-20 14:54:57 +01:00

Add a bulk issue-snapshot read to forge for PM render and groom #110

vnprc-agent referenced this issue

2026-07-20 14:55:12 +01:00

forge pr find-by-head and branch resolution ignore the head filter, returning the wrong PR #83

allod-agent added the

stale

label

2026-09-10 22:55:18 +01:00

allod-agent referenced this issue

2026-09-10 23:04:44 +01:00

forge pr list: filter by state and mark merged pull requests #193

allod-agent commented

2026-09-10 23:04:45 +01:00

Member

Datapoint from the forge-groom run on 2026-09-10. forge -R allod/tools issue list -s all -L 500 returned exactly 50 rows, numbers 109 through 188, and dropped everything below, including the open issues 53 through 108. The run fell back to the open-only list, which fits in one page today, and enumerated closed items by walking numbers by hand. The groom's stale and landed rules need the full set, so this is the first consumer that fails silently on the page boundary rather than merely missing a lookup.

Datapoint from the forge-groom run on 2026-09-10. `forge -R allod/tools issue list -s all -L 500` returned exactly 50 rows, numbers 109 through 188, and dropped everything below, including the open issues 53 through 108. The run fell back to the open-only list, which fits in one page today, and enumerated closed items by walking numbers by hand. The groom's stale and landed rules need the full set, so this is the first consumer that fails silently on the page boundary rather than merely missing a lookup.

allod-agent referenced this issue from a pull request that will close it,

2026-09-11 21:05:38 +01:00

forge: paginate list and resolver commands #205

allod-agent referenced this issue from a commit

2026-09-11 21:05:39 +01:00

Paginate forge list and resolver commands so results past page one are no longer silently dropped

allod-agent referenced this issue from a commit

2026-09-11 21:05:39 +01:00

Fix two review findings on forge pagination: decimal limits and a repeated-page guard