[Bug?]: isAuthenticated=true but currentUser=undefined when dev server restarts #10403
Comments
|
Hey @taivo thanks for reporting the issue ... I'm going to phone a friend and tag one of our core team members who specializes in Supabase + Auth ... stay tuned. |
|
Hi @taivo and thanks for noting this. Some background first --For
This is a dev server only case -- this won't happen when deployed or running in prod. What happens here is that when reloading, both the web and api side reload and the web is faster (sometimes, more than sometimes) than api side (since it assembles the fgraphql schema and such). So, the api just isn't ready yet. But - again - this is dev server only. Maybe when that happens, the auth state needs to be cleared? maybe the reAuth is picking something up from session/localStorage but then the getCurrentUser api call fails and one is set and the other is null. Hm. That could be. @dac09 what do you think about this scenario? Places to lookAlso - the places in the framework auth code you could look at are:
IdeasUser MetadataSince userMetadata is important, perhaps you could try instead of See: userMetadata Try in serve/prod?Instead of running Then try your refresh case as I don't think the api not ready error will happened (fingers crossed). That could be a way to confirm the hypothesis that when api serve isn't available then "auth things get out of sync"? Hope this helps and if you can confirm that behavior, then we'll bee to handle that case better (not sure how just yet)., |
|
@dac09 What do you think about line and if ...try {
const userMetadata = await authImplementation.getUserMetadata()
if (!userMetadata) {
let loading = false
if (authImplementation.clientHasLoaded) {
loading = !authImplementation.clientHasLoaded()
}
setAuthProviderState({
...notAuthenticatedState,
loading,
client: authImplementation.client,
})
} else {
await getToken()
const currentUser = skipFetchCurrentUser ? null : await getCurrentUser()
setAuthProviderState((oldState) => ({
...oldState,
userMetadata,
currentUser,
isAuthenticated: true,
loading: false,
client: authImplementation.client,
}))
}
} catch (e: any) {
setAuthProviderState({
...notAuthenticatedState,
hasError: true,
error: e as Error,
})
}So if But, I wonder if If setAuthProviderState({
...notAuthenticatedState,
})but with no error? Perhaps? |
|
Thanks @taivo for the breakdown and explanation. @dthyresson yeah seems sensible to me! I would've expected the currentUser function to throw though. |
|
Thank you guys, for the fast turn around time. @dthyresson I did some digging into the scenario you provided and you're exactly right!! First off, confirmed that this situation only happens during the first few seconds when the server restarts and is not yet ready. Perhaps this is applicable to production as well as dev. To elaborate, in this code segment else {
await getToken()
const currentUser = skipFetchCurrentUser ? null : await getCurrentUser()
setAuthProviderState((oldState) => ({
...oldState,
userMetadata,
currentUser,
isAuthenticated: true,
loading: false,
client: authImplementation.client,
}))
}
In addition to the consistency issue, we may need to communicate this warm up period to the user somehow, or put some retry logic into getCurrentUser when it gets empty data in the server response. That said, I'm not sure if this is an issue because after setting |
|
@dac09 I ran into an error with the canary upgrade ( Running |
|
Thanks @taivo - yeah sometimes canary can be a little bit flakey. If you have a chance to try again with the newer published version (same command) that'll be great. If not I'll validate this as we upgrade supabase to support ssr as well. |
|
hey @dac09 , I just tried it. Same issue at the canary installation step. If it helps, I'm using a MacBook with Sonoma 14.4.1, Node v20.11.1, yarn 4.1.1. I can try this again for you next week to see if there are any changes. |
|
Hi @dac09 , I was able to install canary After logging in, if I restart the dev server, my app in the browser redirects me to its signin page. Manually navigating away from that signing page clearly shows that I'm still logged in. Update: I've just tested again with latest Thank you for addressing the bug I reported. |
|
Thank you for reporting and the help in validation @taivo ✌️✌️✌️ |
What's not working?
When we kill and restart the dev server, it automatically triggers a browser reload. If there is already a logged in user, this first reload ends up with a situation where
useAuth()propsisAuthenticatedandcurrentUserare of sync (loading=false, isAuthenticated=true but currentUser=undefined).I'm using supabase auth so it's possible this is an issue with that auth adapter.
I ran into this issue while playing with a hook that redirects users to a registration page if they have not claimed a username
currentUser?.username. As soon as the app restarts, this hook redirects an already-registered user to the registration page due to the bug above.My current workaround is to rely on currentUser instead of isAuthenticated for authentication status. When this workaround is in place, the app displays the expected behavior via the graphQL error
The RedwoodJS API server is not available or is currently reloading. Please refresh.My guess is this is a minor cache issue (isAuthenticated initialized from some client-side cache whereas currentUser is fetched from the server). The workaround is simple enough. Just posting in case it correlates with any other strange issues that others may be experiencing.
How do we reproduce the bug?
No response
What's your environment? (If it applies)
No response
Are you interested in working on this?
The text was updated successfully, but these errors were encountered: