Repository navigation
fix(usage): clear auth-expired message for Kiro social-auth (Google/GitHub) accounts - #4512
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Code Review
This pull request updates the Kiro usage service to gracefully handle 401 and 403 authentication errors for social-auth Kiro accounts (Google/GitHub) by returning a friendly 'auth expired' message instead of throwing an error. It introduces a helper function isSocialAuthKiroAccount to identify these accounts, updates the file size baseline, and adds corresponding unit tests to verify the new behavior and ensure that non-social accounts still throw errors as expected. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…ccounts
A Kiro connection added via /api/oauth/kiro/social-exchange (Google or
GitHub social-login device flow) carries a token format that AWS
CodeWhisperer's GetUsageLimits API routinely rejects with 401/403 even
when /messages still works. The quota card was throwing the raw upstream
error blob ("Failed to fetch Kiro usage: Kiro API error (401): {...}"),
which is noisy and unhelpful.
getKiroUsage now detects the social-auth carveout from providerSpecificData
({ authMethod: "imported", provider: "Google" | "Github" } — exactly what
social-exchange/route.ts persists) and returns the same friendly
"Kiro quota API authentication expired. Chat may still work." message
that legacy social-auth users already see. Builder-ID / IDC / kiro-cli
imports keep the existing throw-on-failure behavior so transient upstream
errors don't get silently masked.
TDD: kiro-iam-profilearn-usage.test.ts gets two new cases — the social-auth
path resolves to the friendly message (RED before the fix), and the
non-social Builder-ID path still throws on 401/403 (guards against the
fix overreaching).
Inspired-by: decolua/9router#620
Co-authored-by: Anurag Saxena <anuragg.saxenaa@gmail.com>
dcca183 to
ccacc27
Compare
…iegosouzapw#4512) Rebuilt onto release/v3.8.33; usage.ts baseline reconciled for the diegosouzapw#4493/diegosouzapw#4494/diegosouzapw#4512 quota trio. Integrated into release/v3.8.33.
Summary
A Kiro connection added via
/api/oauth/kiro/social-exchange(Google or GitHub social-login device flow) carries a token format that AWS CodeWhisperer'sGetUsageLimitsquota API routinely rejects with 401/403 even when/messagesstill works.The usage card was throwing the raw upstream error blob:
…which is noisy and tells users nothing. Legacy social-auth users with a different marker already saw the friendly
Kiro quota API authentication expired. Chat may still work.message — newly-added social-auth accounts didn't.Fix
getKiroUsage(open-sse/services/usage.ts) now detects the social-auth carveout fromproviderSpecificData:— exactly the markers
social-exchange/route.tspersists when adding a Kiro account through Google/GitHub. WhenGetUsageLimitsreturns 401/403 and the account matches the carveout, return the friendly message instead of throwing.Builder-ID / IDC /
kiro-cliimports keep the existing throw-on-failure behavior so transient upstream errors don't get silently masked as "auth expired".Files
open-sse/services/usage.ts—getKiroUsagebranch +isSocialAuthKiroAccounthelper (also wired into__testingexport for the new tests)tests/unit/kiro-iam-profilearn-usage.test.ts— two new regression tests (TDD)CHANGELOG.md— entry under[3.8.32]→🐛 Fixedconfig/quality/file-size-baseline.json— bumpopen-sse/services/usage.ts3408 → 3443 (+35 LoC: branch + helper + comments)Test plan
getKiroUsage returns a friendly auth-expired message for social-auth Kiro on 401/403— RED before the fix, GREEN after (asserts/authentication expired/iand thatGetUsageLimitswas actually called after profile discovery).getKiroUsage still throws on 401/403 for non-social Kiro accounts (Builder-ID/IDC)— confirms the fix doesn't overreach and mask transient errors for non-social accounts.kiro-iam-profilearn-usage,kiro-overage-usage-4469,usage-extractor.npm run typecheck:core— clean (exit 0).npx eslint open-sse/services/usage.ts tests/unit/kiro-iam-profilearn-usage.test.ts— clean.node scripts/check/check-file-size.mjs— only pre-existing drift remains (src/lib/db/core.ts,src/lib/usage/providerLimits.ts,src/shared/constants/providers.ts— already over budget onrelease/v3.8.32base); my file matches the bumped baseline exactly.node scripts/check/check-docs-sync.mjs— PASS.Notes
<anuragg.saxenaa@gmail.com>(original upstream fix author — the OmniRoute adaptation is non-trivial because ourgetKiroUsagethrows on non-OK rather than tracking thesawAuthError/authMethodstate machine the upstream patch targets; the carveout had to be moved into the response-handler with social-auth detection derived from OmniRoute's ownproviderSpecificDataschema).DroidToolCard.js+droid-settings/route.jsfor unrelated Droid CLI multi-model support (94% of the upstream diff LoC). Those changes are not in scope for "Kiro quota auth expired" and are not ported here.Inspired-by: decolua/9router#620