Skip to content

fix(profile): stop sending maxResults to ListAvailableProfiles - #164

Closed
18005798765 wants to merge 1 commit into
Quorinex:mainfrom
18005798765:fix/profile-list-drop-maxresults
Closed

18005798765 wants to merge 1 commit into
Quorinex:mainfrom
18005798765:fix/profile-list-drop-maxresults

Conversation

@18005798765

Copy link
Copy Markdown

Summary

ListAvailableProfiles now rejects the maxResults field. Every call from listKiroProfilesInRegionContext returns:

HTTP 400 {"message":"Improperly formed request.","reason":"REQUEST_BODY_INVALID"}

The same request with an empty JSON body {} is accepted:

  • Social (Google) account: 200 {"nextToken":null,"profiles":[]}
  • Builder ID (idc) account: 403 AWS Builder ID is not supported for this operation. This is the error isBuilderIDProfileUnsupportedError already expects.

Because the 400 is neither the Builder ID 403 nor transient, ResolveProfileArn falls through to no available Kiro profile. ensureRestProfileArn then treats that as a hard error, so GetUsageLimits never runs. For Builder ID accounts this means usage and subscription info are never populated. getUsageLimits without a profileArn returns 200 with valid usage for those accounts.

Change

  • Send {} on the first page and only nextToken when paginating. The unused pageSize constant is removed.
  • The pagination test now asserts that the first page body does not contain maxResults.

Testing

  • go test ./proxy/ passes.
  • Deployed on a live instance. A Builder ID account that previously failed refresh with resolve profileArn: no available Kiro profile now refreshes and shows usage, limit, subscription title, and reset date. A social account still refreshes normally.

🤖 Generated with Claude Code

Upstream now rejects the maxResults field on ListAvailableProfiles with
HTTP 400 REQUEST_BODY_INVALID. That 400 is not the Builder ID 403 the
resolver treats as a soft error, so ensureRestProfileArn fails with
"no available Kiro profile" and GetUsageLimits never runs. Builder ID
accounts end up with no usage data even though getUsageLimits works
fine without a profile ARN.

Send an empty body on the first page and only nextToken when paginating.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Mo-cn added a commit to Mo-cn/Kiro-Go that referenced this pull request Oct 5, 2026
…x#151, Quorinex#153, Quorinex#164, Quorinex#150)

- stream: treat meteringEvent as the terminal signal on a clean EOF so
  IdC/Builder ID accounts that never emit metadataEvent stop failing every
  completed turn as "upstream truncated response without stop reason".
  Reasoning-only streams stay truncated and an explicit stopReason
  (e.g. MAX_TOKENS) is never overwritten.
- responses: parse Codex additional_tools input items, flatten namespace
  groups, support custom tools, and emit custom_tool_call / namespace
  fields (upstream PR Quorinex#152, fixes Quorinex#151).
- profiles: stop sending maxResults to ListAvailableProfiles, which upstream
  now rejects with HTTP 400 REQUEST_BODY_INVALID (upstream PR Quorinex#164; also the
  root cause of Quorinex#149 usage-quota failures).
- refresh: skip Builder ID accounts that cannot resolve a profile ARN in the
  background refresh loops (upstream PR Quorinex#153).
- security: generate a random admin password on first run (honouring
  ADMIN_PASSWORD) and warn while the legacy default is still in place (Quorinex#150).
@18005798765 18005798765 closed this by deleting the head repository Oct 12, 2026
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