refactor: improve refresh token persistence and implement automatic session restoration logic in SupabaseAuth#4736
Conversation
…ession restoration logic in SupabaseAuth
There was a problem hiding this comment.
Code Review
This pull request updates the authentication flow in SupabaseAuth.ts by storing the refresh token on any session update and adding a fallback mechanism to manually refresh the web session using a stored token when the initial resolution fails. The review feedback suggests adding a truthiness guard before calling Util.addRefreshTokenToStore with the newly refreshed token to prevent potential runtime errors or store corruption if the token is null or undefined.
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.
| if (response?.data?.session) { | ||
| const { access_token, refresh_token } = response.data.session; | ||
| await this._auth?.setSession({ access_token, refresh_token }); | ||
| Util.addRefreshTokenToStore(refresh_token); | ||
| } |
There was a problem hiding this comment.
Passing refresh_token directly to Util.addRefreshTokenToStore without a truthiness guard can lead to runtime errors or store corruption if the token is null or undefined. Although the Supabase Session type typically includes a refresh_token, certain authentication flows or partial sessions may return a null or undefined value. Adding a guard check before storing the token prevents persisting invalid state, aligning with the pattern used in other parts of this file.
if (response?.data?.session) {
const { access_token, refresh_token } = response.data.session;
await this._auth?.setSession({ access_token, refresh_token });
if (refresh_token) {
Util.addRefreshTokenToStore(refresh_token);
}
}There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 127aa11f1e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (session?.refresh_token) { | ||
| Util.addRefreshTokenToStore(session.refresh_token); | ||
| } |
There was a problem hiding this comment.
Avoid persisting initial sessions before Redux rehydrates
When this listener now runs for every auth event, the INITIAL_SESSION emitted as soon as SupabaseAuth.getInstance() is created can call setRefreshToken. That instance is constructed at module load in src/startup/serviceBootstrap.ts before bootstrapServicesAndRender waits for persistor.bootstrapped, so if the initial-session callback wins the startup race it modifies the auth subtree before redux-persist handles REHYDRATE; the default reconciler then skips the persisted auth state, dropping the stored app user/roles and sending returning users through a logged-out or wrong-mode path. Keep this restricted to real refresh/sign-in completions or defer the dispatch until rehydration is done.
Useful? React with 👍 / 👎.
No description provided.