fix(tui): fill the identity provider pickers past the service page cap - #2237
fix(tui): fill the identity provider pickers past the service page cap#2237aidandaly24 wants to merge 1 commit into
Conversation
The API key and OAuth2 credential provider pickers clamped their page size to 20 rows because ListOauth2CredentialProviders caps maxResults at 20, so a tall terminal showed 20 rows, "more →", and blank space below. Assemble identity list pages in Core the way the gateway connector list does: FilteredPaginator gains an exact-fill mode (no predicate) that asks each scan only for what the page still needs and advances past a page that lands exactly on maxResults, so seams never repeat a row. The documented caps (20 for OAuth2, 100 for API key) move into IdentityClient and the TUI no longer carries a maxPageSize.
|
Claude Security Review: no high-confidence findings. (run) |
There was a problem hiding this comment.
AgentCore Harness Review
Verdict: Looks good
Nice refactor. Moving the Identity service's maxResults caps out of the screen and into IdentityClient is a good separation of concerns, and letting FilteredPaginator operate without a predicate (shrinking requestSize toward remaining on each scan) is a clean way to assemble a page larger than the service page.
A couple of things I traced through and confirmed are correct rather than issues:
- The new
results.length === pageSizeearly-return infilteredPaginator.tsalso fixes a latent bug in the predicate path: previously, landing exactly onpageSizefell into the surplus branch'selseand returnedrequestTokenas the next token, causing the last taken match to repeat on the next page. The updated expectation in thefalls back to defaultPageSizetest (nextToken"1"→"2") reflects that fix, and the pre-existing overshoot/guard tests still hold. Existing predicate callers ineval.tsxandgateway.tsxbenefit from this. identity.test.tsmocks at the SDKsend()boundary and drives realIdentityClient+FilteredPaginatorcode — no excessive mocking.maxResults: 0correctly rejects viaInputValidationError(0 passes theundefinedshort-circuit but failsNumber.isInteger(x) && x >= 1inFilteredPaginator).- No new user-facing feature here that would warrant telemetry.
Ship it.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## refactor #2237 +/- ##
=========================================
Coverage 96.98% 96.99%
=========================================
Files 564 564
Lines 39221 39252 +31
=========================================
+ Hits 38040 38071 +31
Misses 1181 1181 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Summary
identity oauth2-credential-providerandidentity api-key-credential-providerpickers (list, andgetwhich redirects to it) stopped at 20 rows on any taller terminal. The screens clampedmaxResultsto 20 becauseListOauth2CredentialProviderscaps it there;ListApiKeyCredentialProvidersactually allows 100. On a 60-row terminal that meant 20 rows,page 1 · more →, and blank space below.listGatewayConnectorsdoes.FilteredPaginatorgains an exact-fill mode: with nopredicate, each scan asks only for what the page still needs, and a page that lands exactly onmaxResultsadvances past the scan page instead of replaying its token, so a seam never repeats a row. The documented caps (OAuth2 20, API key 100) live inIdentityClient; the TUI no longer carries amaxPageSize.maxResultsstill passes straight through, so the CLI default and the recorded fixtures are unchanged.--max-resultsabove the cap now works in the CLI instead of surfacing a service ValidationException, and a non-positive value is rejected client-side.Before / After
60-row terminal, us-west-2 test account with 30 OAuth2 providers:
page 1 · more →plus 34 blank rows30-row terminal: page 1 shows 23 rows, page 2 starts at item 24 with no duplicates. API key list on 60 rows shows all 46 providers.
Test plan
bun test(3071 pass),bun run typecheck,oxlint, prettiersrc/core/identity.test.ts: page assembly across the cap, token continuity, pass-through with nomaxResults, API key cap of 100, validationfilteredPaginator.test.ts: exact-fill and exact-landing cases. The existing "falls back to defaultPageSize" expectation moves from the replayed token to the advanced one; this is the only behavior change for existing callers (connectors, insights) and it removes a duplicated row at seams that land exactlymore →maxResults=3continues atmaxResults=20with zero overlap; TUI before/after as in the table above