fix(gateway): tolerate transient poll errors during device authorization - #14056
fix(gateway): tolerate transient poll errors during device authorization#14056hobostay wants to merge 1 commit into
Conversation
| const result: PollResult<T> = await pollFn() | ||
| // A thrown poll error (e.g. a transient 5xx or network failure) is not | ||
| // terminal: remember it and keep polling until attempts run out. | ||
| const result: PollResult<T> | undefined = await Promise.resolve() |
There was a problem hiding this comment.
SUGGESTION: Every thrown error is retried, including permanent ones.
pollDeviceAuth (device.ts:38-40) throws for any non-OK status other than 202/403/410, so permanent failures like 400/404 are now retried instead of failing fast. Because maxAttempts is derived from the code expiry (device-auth-tui.ts:37), a permanent error can now keep the sign-in spinner running for the full expiry window (minutes). A 429 is likewise retried on a fixed interval without honoring Retry-After. Consider distinguishing transient (5xx/network) from terminal errors, e.g. an optional retryable predicate on PollOptions, or document that all thrown errors are intentionally retried.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| } | ||
| } | ||
|
|
||
| if (error) throw error |
There was a problem hiding this comment.
SUGGESTION: if (error) can drop the real error and report a stale one.
The truthiness check means a pollFn that rejects/throws a falsy value (undefined, null, 0, "") falls through to the generic timeout message and hides the cause; error !== undefined would be accurate. Separately, error is never cleared after a successful poll, so if an early attempt throws and all later attempts return { continue: true }, exhaustion reports the old transient error instead of the timeout. Consider resetting error to undefined after a successful pollFn call.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (3 files)
Fix these issues in Kilo Cloud Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0 Review guidance: REVIEW.md from base branch |
What
Makes
poll()in@kilocode/kilo-gateway(packages/kilo-gateway/src/auth/polling.ts) tolerate transient errors from the poll function instead of aborting on the first one.Why
During device authorization sign-in, the poll function (
pollDeviceAuth) throws on any non-202/403/410 non-OK status (500/502/429) and on network failures.poll()previously let that throw propagate, so a single transient error — a gateway deploy, a proxy hiccup, a brief network drop — killed the entire login flow while the user was mid-authorization in the browser, forcing them to start over. ThePollResult.errorcontract already distinguishes terminal failures (denied/expired, returned as{ continue: false, error }) from everything else; a thrown request error is not a terminal state and shouldn't end the flow.Now a thrown poll error is treated as a failed attempt: polling continues, and the last error is thrown only once
maxAttemptsis exhausted (instead of the generic timeout message). Terminal result errors still stop polling immediately, and the no-data and timeout paths are unchanged.Testing
Added
packages/kilo-gateway/test/auth/polling.test.tscovering: recovery after transient thrown errors (fails on the previous implementation), last-error propagation with full attempt consumption on exhaustion, immediate stop on terminal result errors, and the unchanged no-error timeout path.bun test(packages/kilo-gateway, 115 pass) andbun run typecheckare green.