[FEATURE] on-call pages list still can't reach current pages once a team's history exceeds 1000 (follow-up to #642 / #670)

[nadimchakra]

Is your feature request related to a problem?

#642 asked for a stable, time-filterable, paginated way to list on-call pages. #670 added on-call pages list, but only as a wrapper around the same unstable endpoint #642 already documented the limitations of — no time filter, no working pagination, oldest-first ordering, and a 1000-record cap.

Once a team's total page count exceeds 1000, its current pages become permanently unreachable through this command. Not delayed — unreachable, since there's no way to skip past the first 1000 results.

Describe the solution you'd like

The original ask from #642: a stable GET /api/v2/on-call/pages list endpoint with real time-window filtering and pagination, exposed as pup on-call pages list --from/--to. The wrapper in #670 was always scoped as a stopgap, not this fix.

Describe alternatives you've considered

If the stable endpoint isn't close, sort the existing unstable-endpoint wrapper newest-first instead of oldest-first. That alone would make --page-size bound "how far back you can see" instead of "how far behind the start of a team's history you are," which is usable for ongoing monitoring even without full pagination.

Additional context

Verified live against pup 1.10.2:

• --page-size returns the oldest N pages, not the most recent N.
• --from, --to, --cursor, --after are all rejected: error: unexpected argument '...' found.
• --page-size is capped at 1000: error: invalid value '5000' ... 5000 is not in 1..=1000.
• Confirmed in src/commands/on_call.rs (Add on-call pages list #670): the query sent is always just page[size] and an optional filter=team:<handle>. No sort, cursor, or time parameter is ever sent.

These match the limitations #642 and #641 already documented before #670 merged — they weren't resolved, just carried forward into the shipped command. At current volume, one team crosses the 1000-record threshold in about a month, at which point this command returns zero current pages for that team with no workaround.

Proposed command syntax (if applicable)

pup on-call pages list --team=<team> --from=2026-08-01 --to=2026-08-07
# or, as a no-backend-work interim fix:
pup on-call pages list --team=<team> --page-size=100 --sort=-created_at

[nadimchakra]

@platinummonkey

Reopening: --sort shipped in v1.10.5 but does nothing. on-call pages list still returns the oldest pages, so #709 is not fixed.

Verified live on pup 1.10.5:

• --sort=-created_at and --sort=created_at return byte-identical output (cmp clean).
• Responses are still strictly ascending by created_at on both teams tested.
• --page-size=3 returns pages from 2025-12-11/12/12. The newest page that run was 2026-08-10T03:22:54Z, last in an 871-record response.
• --sort=bogus is rejected correctly, so argument handling is fine.

pup --no-agent on-call pages list --team=<team> --page-size=3 --sort=-created_at > a.json
pup --no-agent on-call pages list --team=<team> --page-size=3 --sort=created_at  > b.json
cmp a.json b.json   # identical; both return the three OLDEST pages

Cause is the backend, not the CLI. on_call.rs:492 does send sort to /api/unstable/on-call/pages. The endpoint accepts it and drops it.

#710's tests can't catch that. They're mockito mocks asserting only that pup emits the param (on_call.rs:966), and per the PR body they never ran locally (cargo 403 on the pinned dep).

Ask, in preference order:

• Make the endpoint honor sort, verified against real data rather than a mock.
• Otherwise revert the default to created_at and drop the newest-first claim from --help.
• The real fix is still the stable GET /api/v2/on-call/pages from on-call: no way to list pages by team or responder (stable v2 list returns empty) #642, which returns an empty body today.

Cap deadline stands: 871/1000 at 1.6 pages/day reaches the limit around 2026-10-29, at which point current pages become unreachable.