Assuming that the app uses localStorage to store tokens and 1hr refresh rates, there are 3 possible states when a page is loaded initially: 1) No token is found in localStorage (e.g. user visits the page for the first time on this browser) - this means that supabase.auth.user() will return null and supabase.auth.onAuthStateChanged() will not dispatch an event UNLESS we explicitly call supabase.auth.signIn(); 2) A valid supabase token (i.e. one which is NOT expired) is found in localStorage - this means that a call to supabase.auth.user() will return the current user immediately after the supabase initialization is completed 3) A supabase token is found in localStorage, however, it is expired and needs to be refreshed with the refresh token from local storage - this means that supabase.auth.user() will return null immediated after supabase is initialized but will return non-null once the token is refreshed (assuming the refresh token is valid). The client code can start listening for onAuthStateChanged() immediately after supabase initialization and that way it will know once user is refreshed

The problem I see with this is that there is no way for the client library to differentiate between case (1) and (3) BEFORE any events are dispatched against onAuthStateChanged. If it is case (1), an event will never be dispatched, but the client has no way of knowing this unless the client manually inspects the contents of localStorage (which doesn't seem like a good idea because it uses supabase internal state). Note, that Firebase does NOT seem to suffer the same problem because firebase.auth().onAuthStateChanged is guaranteed to fire at least once after subscribing to it (at least accoring to https://medium.com/firebase-developers/why-is-my-currentuser-null-in-firebase-auth-4701791f74f0). Am I missing something?

(This is all in a web context -- I don't know if it would look different natively)

Anyway, the upshot is that for me the

useEffect(()=> {//listen for auth event},[])

pattern discussed in the post you linked earlier and implemented in the UserContextProvider function here (https://github.com/supabase/ui/blob/master/src/components/Auth/UserContext.tsx) works perfectly -- EXCEPT that I believe this implementation is buggy.

I've opened an issue to talk about that here: https://github.com/supabase/ui/issues/291

After making the change I discuss there, I have exactly what I need: 1) A loading state (session === undefined), which is always the state on page load, whether there's fresh data or not. 2) A no-valid-user state (session === null), which only occurs once the client has attempted and failed to recover valid user data. 3) A valid user state (session != null && session != undefined), which occurs when valid data is present or can be fetched. ----- Because that's all working robustly for me now, I suspect that the events you're talking about are firing correctly -- but it's also possible I've missed your point, and there's a different case where they're not working.

Basically, it depends on whether the token refresh request returns BEFORE or AFTER react gets to update the state of UserContextProvider component (which happens async since it's done via React's setState())

so unless I am wrong about how setState() works or I am missing something else - the problem I describe still exists

@User Seems like there is ONE more case which is not handled, it's similar to (3) above, but instead of having to refresh a token for an existing user, it's about confirming a newly registered using when they click on the confirmation link sent to their email

You can see how to detect this case here: https://github.com/supabase/gotrue-js/blob/0ae593b353c56487aaf0ea4084d5a3de89b37515/src/lib/helpers.ts#L16

Access to supabase.auth.user() on initial load