feat(cli): add server-side pagination - #708
Merged
Merged
Conversation
- Pages platform-domain and social-provider resolution via admin list APIs - Resolves DNS zones by paging ListZonesPage instead of the first page - Passes paging through API-key service listing - Bumps ipfs-sdk, portal-sdk, and pinner to the paged list releases - Regenerates the API-key service mock for the paginated signature
This comment has been minimized.
This comment has been minimized.
![kody-ai[bot]](https://avatars.githubusercontent.com/in/413034?s=60&v=4){kind=small}
Code Coverage ReportTotal Coverage: 55.3% Generated from commit: 9c3332c |
The account api-keys list and delete-by-name paths called ListAPIKeys with a zero window, so the backend's default 10-row page truncated results: the list rendered only the first page while reporting the full count, and deleting a key by name past the first page failed. - Add an allAPIKeys full-scan helper that walks explicit start/limit windows until every key is collected, mirroring the allPlatformDomains/allSocialProviders pattern - Use it in the list handler so all keys are shown - Use it in delete-by-name resolution so keys beyond the first page resolve to their UUID before deletion - Add regression tests covering a >10-key list and name resolution past the first page
This comment has been minimized.
This comment has been minimized.
pcfreak30
marked this pull request as ready for review
September 15, 2026 20:05
…scanning accountAPIKeysDelete resolved a name to its UUID by full-scanning every API key (allAPIKeys with an empty search), so the backend returned the account's whole key set. Pass the provided name as the backend search filter so the backend narrows the pages, while keeping allAPIKeys' paginated scan (explicit start/limit windows plus the short-page/total termination guards) so a match past the backend's default first page still resolves before deletion. Update the regression test to prove filtered paging reaches a key beyond the first page: keys share a common prefix so the name search returns multiple full pages of filtered rows, the exact-name target sits past the first page, and every paged request carries the name as the search filter.
Kody Review CompleteGreat news! 🎉 Keep up the excellent work! 🚀 Kody Guide: Usage and ConfigurationInteracting with Kody
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reworks admin platform-domain and social-provider lookups, DNS zone resolution, and API-key listing to use the paged list APIs from the latest pinner, ipfs-sdk, and portal-sdk releases.
Bumps ipfs-sdk to v0.1.99, portal-sdk to v0.1.74, and pinner to the current develop head, and regenerates the API-key service mock for the paginated signature.
Pull Request Description
Title: feat(cli): add server-side pagination
Summary:
The backend APIs used by several CLI commands now apply a default 10-row window to their list endpoints. Previously, CLI flows that resolved resources by name read only the first page returned, so any item beyond the first 10 rows was silently missed. This PR updates those flows to support server-side pagination.
Key changes:
internal/cli/catalog_admin_wiring.go): Name/ID lookups for platform domains and social providers now page through the entire dataset using_start/_endwindow parameters (100 items per page) until the backend-reported total is reached. This ensures items past the first default window can still be resolved.internal/cli/dns.go): Zone lookup now pages throughListZonesPagewith start/limit options instead of relying on the non-paginatedListZoneswrapper, which only returns the first window.internal/cli/account_api_keys.go): TheListAPIKeysinterface now acceptsstartandlimitparameters, and the list/delete flows pass pagination arguments through to the service.ListAPIKeyswith start/limit,ListPlatformDomainswith params, plus newListZonesPage/ListKeysPagemock methods).Known review findings:
allPlatformDomains/allSocialProviderspagination loops can iterate forever and grow the accumulated result slice unboundedly when the backend reports no global total or returns full pages regardless of the requested window; the break condition relies entirely ontotal > 0.ListAPIKeyswith a zero window (0, 0), which returns only the default 10-row window while still reporting the full total, truncating any keys past the first 10.