useUser() and loading.tsx are braking next.js' revalidatePath()

[Chenalejandro]

When using useUser() and loading.tsx, the next.js revalidatePath() will not work correctly.

Steps to reproduce:

1. clone https://github.com/Chenalejandro/stack-auth-bug
2. fill env variables
3. pnpm install && pnpm dev
4. login and go to the root page
5. then, there is an input to change the displayName. Fill a new name and click the button "Change user name".

Expected: the input field will be showing the new displayName.
Actual: the input field will show the previous displayName.

This bug only happens in the first server action invocation after page refresh. Subsequent server action invocation will revalidate the path correctly.

This issue happens in both dev and production, local or deployed.

The example udpates the displayName, but it can be anything that changes some data and uses revalidatePath() to refresh the page.

I'm not sure if this is a bug caused by next.js itself or by stack-auth. I checked the issues from next.js and the only one that might be related is vercel/next.js#66431

The workaround is to not use useUser() and remove loading.tsx. Just pass the user data from a parent RSC to the child client component.
Update: this doesn't work since the /handler/[...stack] still needs the loading.tsx file
Second update: just move everything related to the stack-auth to a route group and use the loading.tsx there

Please feel free to contact me if you need any further information.

[N2D4]

Also not sure yet if this is our mistake or Next.js (suspicion is on the latter), but definitely something that should be fixed. Maybe we should also stop depending on loading.tsx in the Handler component for the moment, that would lessen the impact of this.

Thanks for the report!

[Chenalejandro]

from my quick test with the latest next.js canary the bug is fixed. We just need to wait next.js 15 to confirm that the bug is gone and close this issue.

Edit: Confirming that the bug is gone in next.js 15