Skip to content

fix: add pagination support for App Store Connect API list endpoints#2

Open
EdouardF wants to merge 1 commit into
thatfactory:mainfrom
EdouardF:fix/pagination
Open

fix: add pagination support for App Store Connect API list endpoints#2
EdouardF wants to merge 1 commit into
thatfactory:mainfrom
EdouardF:fix/pagination

Conversation

@EdouardF
Copy link
Copy Markdown

Problem

All list methods (ProductsClient.list, WorkflowsClient.listForProduct, BuildsClient.listForWorkflow) returned only the first page of results, silently discarding subsequent pages.

When a workflow has more builds than the default page limit (typically 100), buildSelector=latest would return stale data — e.g., returning build #186 instead of the actual latest build #228+.

The Apple App Store Connect API paginates responses using links.next URLs in the response envelope, but these were never followed.

Root Cause

BaseAPIClient.get() returns APIResponse<TData> which includes links.next, but all callers just extracted response.data and returned it, ignoring pagination entirely.

Changes

  • BaseAPIClient.listAll() — New protected method that follows links.next URLs to collect all pages of paginated responses
  • BuildsClient.listForWorkflow() — Now uses listAll() with limit=200, removed unused limit parameter
  • ProductsClient.list() — Now uses listAll() with limit=200, removed unused limit parameter
  • WorkflowsClient.listForProduct() — Now uses listAll() with limit=200, removed unused limit parameter
  • build-locator.ts — Removed hardcoded limit=100 since listForWorkflow now fetches all pages
  • discovery.ts — Simplified tool schemas (removed manual limit params since pagination is automatic)
  • build-runs.ts — Updated to match new client signatures
  • tests/pagination.test.ts — New test suite covering single page, multi-page, empty, and two-page scenarios

Testing

All 25 tests pass, including 4 new pagination-specific tests:

✔ listAll collects items from a single page with no next link
✔ listAll follows pagination links across multiple pages
✔ listAll returns empty array when first page has empty data
✔ listAll handles two pages correctly

Breaking Changes

  • BuildsClient.listForWorkflow(workflowId, limit?)listForWorkflow(workflowId) (removed limit parameter)
  • ProductsClient.list(limit?)list() (removed limit parameter)
  • WorkflowsClient.listForProduct(productId, limit?)listForProduct(productId) (removed limit parameter)

These were internal API changes only — the MCP tool interface remains compatible.

All list methods (ProductsClient.list, WorkflowsClient.listForProduct,
BuildsClient.listForWorkflow) previously returned only the first page
of results, silently discarding subsequent pages. With 100+ builds
in a workflow, this meant buildSelector=latest returned stale data.

Changes:
- Add BaseAPIClient.listAll() method that follows links.next URLs
  to collect all pages of paginated responses
- Update BuildsClient.listForWorkflow to use listAll with limit=200
- Update ProductsClient.list to use listAll with limit=200
- Update WorkflowsClient.listForProduct to use listAll with limit=200
- Remove unused limit parameter from client list methods (MCP tools
  now paginate automatically)
- Update build-locator.ts to remove hardcoded limit=100
- Add pagination tests for listAll (single page, multi-page, empty)
- All 25 tests pass

Fixes the issue where buildSelector=latest would return build #186
instead of the actual latest build #228+.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant