feat(list): auto-paginate by default #34

Merged

David merged 1 commit from feat/list-auto-paginate into main

2026-05-14 19:52:55 +02:00

David commented

2026-05-14 19:47:09 +02:00

Owner

Summary

Fixes the user-visible symptom that prompted this PR: yt list --assignee me returning a short table (or appearing empty) on an instance that has more issues than YouTrack's default page size (~42), with no warning or error.

Why

The default fetch_issues path sent one GET /api/issues?query=... request with no $top. YouTrack applies its server-side default page size (around 42) and silently drops the rest of the matches. From the user's seat that looks identical to a working query returning zero hits.

What changes

Auto-pagination is now the default. With no --top / --skip, the CLI loops fetch_issues_page with $top=100 and rising $skip until a short page comes back. --top and --skip still opt in to single-page mode (useful for cursoring or capping huge result sets).
--all is preserved as a hidden no-op alias so existing scripts keep working.
Each page boundary logs at tracing::info! (skip / page_size / page_len) plus a final total. yt -v list makes pagination visible when debugging "I expected more results than appeared."

Separate fix in the same path

fetch_issues_page previously dropped sprint sub-fetch errors with if let Ok(...) and emitted nothing. Now matches the existing fetch_issues pattern: tracing::warn! with the issue id and error message, so a 401/403/timeout on /api/issues/<id>/sprints shows up under -v instead of disappearing. The sprint column stays empty when a sub-fetch fails (unchanged).

Test plan

cargo fmt --all
cargo clippy --all-targets --all-features -- --deny warnings
cargo test --all-targets (204 passed; was 202)
New test list_paginates_by_default: 100-item full page plus a 1-item tail, asserts both pages are fetched (mocks $skip=0 and $skip=100 separately)
New test list_with_top_disables_auto_pagination: --top 5 triggers a single request
Manual: against an org with >50 matching issues, yt list --assignee me now returns every issue rather than a truncated table
Manual: yt -v list --assignee me prints page boundaries and a final total

## Summary Fixes the user-visible symptom that prompted this PR: `yt list --assignee me` returning a short table (or appearing empty) on an instance that has more issues than YouTrack's default page size (~42), with no warning or error. ### Why The default `fetch_issues` path sent one `GET /api/issues?query=...` request with no `$top`. YouTrack applies its server-side default page size (around 42) and silently drops the rest of the matches. From the user's seat that looks identical to a working query returning zero hits. ### What changes * **Auto-pagination is now the default.** With no `--top` / `--skip`, the CLI loops `fetch_issues_page` with `$top=100` and rising `$skip` until a short page comes back. `--top` and `--skip` still opt in to single-page mode (useful for cursoring or capping huge result sets). * `--all` is preserved as a hidden no-op alias so existing scripts keep working. * Each page boundary logs at `tracing::info!` (skip / page_size / page_len) plus a final total. `yt -v list` makes pagination visible when debugging "I expected more results than appeared." ### Separate fix in the same path `fetch_issues_page` previously dropped sprint sub-fetch errors with `if let Ok(...)` and emitted nothing. Now matches the existing `fetch_issues` pattern: `tracing::warn!` with the issue id and error message, so a 401/403/timeout on `/api/issues/<id>/sprints` shows up under `-v` instead of disappearing. The sprint column stays empty when a sub-fetch fails (unchanged). ## Test plan - [x] `cargo fmt --all` - [x] `cargo clippy --all-targets --all-features -- --deny warnings` - [x] `cargo test --all-targets` (204 passed; was 202) - [x] New test `list_paginates_by_default`: 100-item full page plus a 1-item tail, asserts both pages are fetched (mocks `$skip=0` and `$skip=100` separately) - [x] New test `list_with_top_disables_auto_pagination`: `--top 5` triggers a single request - [ ] Manual: against an org with >50 matching issues, `yt list --assignee me` now returns every issue rather than a truncated table - [ ] Manual: `yt -v list --assignee me` prints page boundaries and a final total

David added 1 commit

2026-05-14 19:47:09 +02:00

feat(list): auto-paginate by default; surface sprint sub-fetch errors

Check / fmt + clippy + build + tests (pull_request) Successful in 14s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

bdb2f1d18e

`yt list` previously sent one request with no `$top`, so YouTrack used its server-side default (about 42 issues) and silently dropped the tail of any longer result set. From the user's seat that is indistinguishable from a working query that returned zero hits: no error, no warning, just a short table. Reported in the wild against an org whose `--assignee me` had more than one page of results.

Auto-pagination is now the default: with no `--top` / `--skip`, the CLI loops `fetch_issues_page` with `$top=100` and rising `$skip` until a short page comes back. `--top` and `--skip` still opt in to single-page mode (useful for `$skip` cursoring or capping huge backlogs). `--all` is preserved as a hidden no-op alias so existing scripts keep working without surprises.

Each page boundary now logs at `tracing::info!` level (skip, page_size, page_len) plus a final total, so `yt -v list` makes the pagination visible when debugging "I expected more results than appeared."

Separately, fix a latent bug in `fetch_issues_page`: the sprint sub-fetch dropped errors with `if let Ok(...)` and offered no signal. Now it logs at `tracing::warn!` matching the pre-existing pattern in `fetch_issues`, so a 401/403/timeout on the sprints endpoint shows up under `-v` instead of disappearing.

Two new wiremock tests pin the new behavior: one builds a 100-item full page plus a 1-item tail and confirms both pages are fetched; the other confirms `--top` keeps the request count at one.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>