feat(auth): token refresh retry on 401 responses

[trungvose]

Summary

• Added tryRefreshToken() public method to AuthStore that refreshes the Spotify access token, persists new tokens to localStorage and store state, and returns the new access token
• Rewrote UnauthorizedInterceptor to silently refresh expired tokens on 401 responses (up to 2 attempts) and replay the original failed request with the fresh token
• Token expired modal now only appears after both refresh attempts fail — previously it showed immediately on any 401

Flow

Request → API → 401 response
  │
  ├─ Is a refresh already in progress?
  │    ├─ YES → wait for it to complete, get new token, replay request
  │    └─ NO  → attempt 1:
  │              │
  │              ├─ authStore.tryRefreshToken() succeeds
  │              │    → replay original request with new Bearer token
  │              │
  │              └─ fails → attempt 2:
  │                   ├─ succeeds → replay original request
  │                   └─ fails → uiStore.showUnauthorizedModal()
  │                        → return error

Test plan

• 5 unit tests for AuthStore.tryRefreshToken() (success, localStorage persistence, state update, missing token error, API error propagation)
• 8 unit tests for UnauthorizedInterceptor (passthrough, non-401 errors, skip URLs, refresh+replay, 2 failures then modal, second attempt success, concurrent 401 coalescing, concurrent failure propagation)
• Build succeeds with no compile errors
• Manual: clear access_token from localStorage while app is running → verify silent refresh
• Manual: clear both access_token and refresh_token → verify modal appears

🤖 Generated with Claude Code

[devin-ai-integration]

Devin Review found 1 potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 Unbounded reconnect loop on authentication_error when token is still invalid

The authentication_error handler calls player.disconnect() then player.connect() with no retry limit, delay, or guard. When connect() runs, it invokes the getOAuthToken callback at playback.service.ts:53, which reads the token from localStorage. If the token in localStorage is still stale (e.g., the interceptor's 401 refresh hasn't completed yet, or the refresh itself failed), the SDK receives the same invalid token, fails to authenticate, and fires authentication_error again — creating a tight infinite loop of disconnect→connect→authenticate→fail→disconnect→connect… This will spam Spotify's servers with rapid WebSocket connection attempts, flood the console, and potentially freeze the browser tab.

Prompt for agents

The authentication_error listener in playback.service.ts (lines 62-66) calls player.disconnect() then player.connect() unconditionally, with no retry limit or backoff. If the token stored in localStorage is still invalid when connect() triggers getOAuthToken, the SDK will fail again and fire authentication_error again, creating an infinite loop.

To fix this, add a reconnect attempt counter and a maximum retry limit (e.g., 3 attempts). Additionally, consider adding an exponential backoff delay (e.g., using setTimeout) between reconnect attempts. Reset the counter on a successful ready event. If the max retries are exceeded, log a final error and stop retrying.

Relevant code:
- playback.service.ts lines 62-66: the authentication_error handler
- playback.service.ts lines 52-53: the getOAuthToken callback that reads from localStorage
- playback.service.ts lines 97-103: the ready listener that fires on successful reconnect (good place to reset the counter)

---

Was this helpful? React with 👍 or 👎 to provide feedback.