fix(settings): keep Refresh result from being clobbered by stale auth check#26
Conversation
… check When SettingsView mounts, loadConfig auto-runs checkAuthStatus against the stored endpoint. If the user changes the endpoint and clicks Refresh before the first response lands, two checks race — and the slower response (often the older one) overwrites the newer one, so the UI ends up showing auth for the previous endpoint. Track a per-call ID on a ref and discard responses that aren't from the latest invocation; gate setCheckingAuth(false) on the same check so the spinner stays up until the newest call resolves. Also harden the avatar proxy along the way: derive the endpoint from the avatar URL's origin instead of stored config (so the avatar still loads on fresh installs and unsaved endpoint changes), and add the Strategy-2 Authorization-header fallback that checkAuthentication already does.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
WalkthroughThis pull request addresses avatar proxy handling and race conditions in authentication state management. The avatar proxy handler now derives the API origin directly from the avatar URL, constructs auth configuration per method type, and implements JWT retry logic on 401 responses using an Authorization header. The authentication hook now tracks each Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Summary
useSettingsForm.checkAuthStatus: when SettingsView mounts,loadConfigauto-runs an auth check against the stored endpoint. If the user changes the endpoint and clicks Refresh before the first response lands, both checks race — and whichever response arrives last writes to React state, so the UI ends up showing auth for the previous endpoint. Tracked with a per-call ID ref so only the latest call's response is honored.checkAuthenticationalready does.avatarFailedwhenever a new auth check starts, so a stale failed-load state can't suppress a successful refresh when the proxy URL string is unchanged.Test plan
npx jest background/handlers/__tests__/avatar-proxy.test.ts— 20 passed (4 new)npx jest src/hooks/__tests__/useSettingsForm.race-condition.test.tsx— 2 passed (new)npx jest --testPathPatterns="(SettingsView|useSettingsForm|auth\.|AuthenticationStatus|avatar)"— 98 passedSummary by CodeRabbit
Release Notes – v1.5.1
Bug Fixes
New Features