fix(mobile): stop sign-in retry loop on terminal auth failures

[iscekic]

Changelog for users

• The app stops retrying a refused sign-in and returns you to the sign-in screen.
• A credential the server rejects is cleared instead of being reused on every foreground.
• A throttled sign-in waits at least as long as the server asks before trying again.
• A refused refresh from an earlier session no longer signs out a session you started afterward.

Changelog for maintainers

• apps/mobile/src/lib/auth/credentials.ts:226 — accepted: a rejected keychain delete was downgraded to a retryable refresh; the clear now uses Promise.allSettled and still reports the terminal refusal.
• apps/mobile/src/lib/auth/device-auth-poll.ts:145 — accepted: a retry wait used the whole budget, letting a large Retry-After double the timeout; the wait is now capped by the time left, and the budget check is inclusive.
• apps/mobile/src/lib/auth/auth-context.tsx:638 — accepted: a refusal from an older session could sign out a newer one; refusals now carry their sessionVersion and sign out only while it is current.
• apps/mobile/src/lib/auth/credentials.ts:104 — accepted: the 401 clear dropped the in-memory owner before sign-out's remote cleanup, so the revoke and push unregister ran unauthenticated. The clear now deletes only the stored pair; sign-out's teardown still clears the owner after cleanup.
• A shared classifier maps native auth POSTs to success, terminal, or retry; a 401 and any 4xx without retry guidance are terminal and never retried. Terminal failures report once per process with the fingerprint [auth-terminal, route, status]. Start review at auth-response-class.ts, then the epoch-guarded clear in credentials.ts.
• Only a refresh-route 401 clears the stored bearer pair; a native/token or passkey 401 is terminal for that attempt without clearing a healthy session.
• The proactive refresh path signs the person out when a refresh is refused and leaves a transient refresh alone; refresh exposes retryAfterMs parsed from Retry-After on 429/5xx, and the device-auth poll waits max(its backoff, Retry-After) capped by the remaining budget.
• The earlier stub-run excerpts and the failed CLI test excerpt are removed as superseded; the Android emulator device-auth run appended in the proof section replaces them and shows the poll wait capped by the remaining budget. The sign-in-POST 429 wait is not claimed live.

E2E proof

Owner request

Surface: mobile-app

The app retries a failed sign-in call forever instead of stopping and asking the
user to sign in again.

The evidence (production)

• KILO-APP-JF, 141 events: POST https://api.kilo.ai/api/auth/native/token -> 401
• KILO-APP-K9, 87 events: POST https://api.kilo.ai/api/auth/native/otp -> 429
• KILO-APP-18E: POST https://api.kilo.ai/api/auth/native/refresh -> 401

A 401 means the credential is gone. A 429 means the client is asking too often.
Both repeat on one client, so the retry loop is the defect: the app treats a
terminal sign-in failure as a retryable one.

What to build

1. Classify the sign-in responses. A 401 on native/token or native/refresh
   is terminal: clear the stored credential, stop the loop, and send the user to
   sign in.
2. Back off on a 429 and honour Retry-After. Do not retry a 4xx that carries
   no retry guidance.
3. Report each terminal failure once, with a stable fingerprint, instead of once
   per retry.

Proof

One must-run scenario that signs in, invalidates the credential, and shows the
app stopping the loop and reaching the sign-in screen. Quote the decisive log
lines in the pull request body, including the response code and the retry stop.

E2E proof — log excerpts

[e1] device sign-in: a 429 with Retry-After larger than the remaining poll budge -> pass :: Android emulator-5554: with a stub answering the device-auth poll, e1-stub.log records one poll 'POST /api/device-auth/token -> 429 Retry-After: 600' and no second poll, and the app then rendered 'Sign-in timed out. Please try again.' at the 5-minute budget (e1-digest.txt), so the wait was capped by the remaining budget rather than waiting out the 600 s Retry-After; screenshots e1-pending.png/e1-timed-out.png are for the visual reviewer; no UX defect observed.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental commit 7a13bc7 makes the device-auth foreground poll honor the server's Retry-After cooldown through a throttledUntil deadline in apps/mobile/src/lib/auth/device-auth-poll.ts, and adds a regression test that foregrounds inside the cooldown; the deadline is always at or before the retry timer it was scheduled with, so it cannot strand pollNow, and the earlier terminal-auth findings remain addressed. No new issues were found in the changed lines.

Files Reviewed (2 files)

• apps/mobile/src/lib/auth/device-auth-poll.ts
• apps/mobile/src/lib/auth/device-auth-poll.test.ts

All other files in the PR diff are unchanged since the previous review and were not re-flagged. Existing findings are fixed at this commit: the 401 clear reports the terminal refusal via Promise.allSettled while leaving the in-memory owner for sign-out's cleanup, the retry wait is capped by the remaining poll budget, and refusals are epoch-scoped before sign-out.

Previous Review Summaries (3 snapshots, latest commit cc84825)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit cc84825)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental changes since the previous review are correct and well-tested: the refresh-route 401 clear is epoch-scoped and best-effort (Promise.allSettled) while still returning refused: true, the in-memory owner keeps serving until sign-out's teardown clears it, the device-auth poll wait is capped by the remaining budget with an inclusive boundary check, refusals carry their sessionVersion and sign out only while current, and the new shared classifier reports each terminal failure once per process; no new issues were found in the changed lines.

Files Reviewed (13 files)

• apps/mobile/src/lib/auth/auth-context.lifecycle.test.tsx
• apps/mobile/src/lib/auth/auth-context.test.ts
• apps/mobile/src/lib/auth/auth-context.tsx
• apps/mobile/src/lib/auth/auth-fetch.test.ts
• apps/mobile/src/lib/auth/auth-fetch.ts
• apps/mobile/src/lib/auth/auth-response-class.test.ts
• apps/mobile/src/lib/auth/auth-response-class.ts
• apps/mobile/src/lib/auth/credentials.ts
• apps/mobile/src/lib/auth/device-auth-poll.test.ts
• apps/mobile/src/lib/auth/device-auth-poll.ts
• apps/mobile/src/lib/auth/poll-response.test.ts
• apps/mobile/src/lib/auth/poll-response.ts
• apps/mobile/src/lib/auth/refresh-terminal.test.ts

Previous review (commit d1f212e)

Status: No Issues Found | Recommendation: Merge

Executive Summary

All three prior findings on the mobile terminal-auth changes are fixed at HEAD — the refresh clear is best-effort yet still reports the terminal refusal, the device-auth retry wait is capped by the remaining poll budget, and refusals are epoch-scoped before sign-out — and no new issues were found in the changed code.

Files Reviewed (7 files)

• apps/mobile/src/lib/auth/auth-context.tsx
• apps/mobile/src/lib/auth/auth-context.lifecycle.test.tsx
• apps/mobile/src/lib/auth/auth-context.test.ts
• apps/mobile/src/lib/auth/credentials.ts
• apps/mobile/src/lib/auth/device-auth-poll.ts
• apps/mobile/src/lib/auth/device-auth-poll.test.ts
• apps/mobile/src/lib/auth/refresh-terminal.test.ts

Previous review (commit a9571af)

Status: 3 Issues Found | Recommendation: Address before merge

Executive Summary

The terminal-auth classification is sound, but a failed credential delete in doRefresh can silently downgrade a terminal 401 back into the retryable loop this PR removes; two lower-severity issues concern poll-budget and epoch handling.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	2

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/mobile/src/lib/auth/credentials.ts	226	A rejected SecureStore delete is caught by doRefresh's outer catch and returned as { ok: false, refused: false }, so a terminal 401 is reported as transient, the dead pair is kept, and the retry loop resumes.

SUGGESTION

File	Line	Issue
apps/mobile/src/lib/auth/device-auth-poll.ts	145	Retry wait is capped at the full POLL_OVERALL_TIMEOUT_MS rather than the remaining budget, so a large Retry-After can push the timeout past the intended deadline (up to ~2x budget).
apps/mobile/src/lib/auth/auth-context.tsx	638	The added signOut(true) on a refused proactive refresh is not gated on the captured epoch; combined with single-flight performRefresh, a refused outcome from an older session can tear down a newer sign-in.

Files Reviewed (11 files)

• apps/mobile/src/lib/auth/auth-context.tsx - 1 issue
• apps/mobile/src/lib/auth/auth-fetch.ts - no issues
• apps/mobile/src/lib/auth/auth-fetch.test.ts - no issues
• apps/mobile/src/lib/auth/auth-response-class.ts - no issues
• apps/mobile/src/lib/auth/auth-response-class.test.ts - no issues
• apps/mobile/src/lib/auth/credentials.ts - 1 issue
• apps/mobile/src/lib/auth/device-auth-poll.ts - 1 issue
• apps/mobile/src/lib/auth/device-auth-poll.test.ts - no issues
• apps/mobile/src/lib/auth/poll-response.ts - no issues
• apps/mobile/src/lib/auth/poll-response.test.ts - no issues
• apps/mobile/src/lib/auth/refresh-terminal.test.ts - no issues

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 main}

[iscekic]

kilo-review — independent audit of the published diff.

Status: 1 Issues

File	Line	Issue
apps/mobile/src/lib/auth/credentials.ts	104	The new clear deletes the stored pair and empties the in-memory token owner before the refusal-triggered signOut runs, so sign-out's runLogoutCleanup (revokeCurrentDeviceSession, unregisterPushToken) is sent with no Authorization header and fails, where before the change the owner still served the access token to that cleanup.

[iscekic]

bot: Accepted. Pushed 2f83fc7 (kwf kwf-fix-review-7270).

What changed:

• apps/mobile/src/lib/auth/credentials.ts:226 — accepted: a rejected keychain delete was downgraded to a retryable refresh; the clear now uses Promise.allSettled and still reports the terminal refusal.
• apps/mobile/src/lib/auth/device-auth-poll.ts:145 — accepted: a retry wait used the whole budget, letting a large Retry-After double the timeout; the wait is now capped by the time left, and the budget check is inclusive.
• apps/mobile/src/lib/auth/auth-context.tsx:638 — accepted: a refusal from an older session could sign out a newer one; refusals now carry their sessionVersion and sign out only while it is current.
• apps/mobile/src/lib/auth/credentials.ts:104 — accepted: the 401 clear dropped the in-memory owner before sign-out's remote cleanup, so the revoke and push unregister ran unauthenticated. The clear now deletes only the stored pair; sign-out's teardown still clears the owner after cleanup.
• A shared classifier maps native auth POSTs to success, terminal, or retry; a 401 and any 4xx without retry guidance are terminal and never retried. Terminal failures report once per process with the fingerprint [auth-terminal, route, status]. Start review at auth-response-class.ts, then the epoch-guarded clear in credentials.ts.
• Only a refresh-route 401 clears the stored bearer pair; a native/token or passkey 401 is terminal for that attempt without clearing a healthy session.
• The proactive refresh path signs the person out when a refresh is refused; a transient refresh leaves the session alone.
• Refresh exposes retryAfterMs parsed from Retry-After on 429/5xx; the device-auth poll waits max(its backoff, Retry-After) capped by the remaining budget.