I think the main difference between Firebase and Supabase is that in Firebase, you would get this behavior EVEN if the client's token is NOT expired (since Firebase does async fetching from localStorate) while in Supabase, you should see this behavior ONLY if the user's token has expired and needs to be refreshed (at least that's what it looks like when looking at GoTrue.js code)

As you can see in the referenced blog post, one way to resolve this is to create your own wrappers around auth.user/auth.session AND to introduce a third state (i.e. unknown) so that you can show a spinner/loader to the user until you get the actual state

Does this help?

especially handy to see the same workarounds are called for in Firebase

it feels... under-documented for a piece of boilerplate that's essentially mandatory to make the function act in a predictable manner, but that might only be biting newbies

(that is, I have trouble imagining a case where I'd want a call to

auth.user

to return null when there's valid data in local storage)

Hi again @User , it seems that supabase actually has a bug around this ...OR I don't fully understand how it works

The issue as I see it is that the supabase client does NOT deliver a SIGNED_OUT event if there is no session stored in localstorage...(according to the blog post I mentioned above, Firebase guarantees deliviery of at least one event onceyou register)

basically this means that you can start in a pending state and switch to a sign_in/sign_out state only after the first onAuthStateChanged event (as it is done in Firebase)

I will start another thread around this particular issue and see if anyone else has insights