github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

Session store updates delayed which result in routing errors #463

New Issue
Closed
opened 2026-03-13 07:48:27 -05:00 by GiteaMirror · 14 comments
GiteaMirror commented 2026-03-13 07:48:27 -05:00
Owner
Copy Link

Originally created by @k3dom on GitHub (Dec 24, 2024).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Setup a Tanstack Router/Start project with a authenticated routes as recommended here

main.tsx:

function App() {
  const { data: session } = useSession()

  return (
    <StrictMode>
        <RouterProvider
          router={router}
          context={{ authSession: session?.session }}
        />
    </StrictMode>
  )
}

const rootElement = document.getElementById('root')!
if (!rootElement.innerHTML) {
  createRoot(rootElement).render(<App />)
}

_authenticated.tsx:

export const Route = createFileRoute('/_authenticated')({
  beforeLoad: async ({ location, context: { authSession } }) => {
    if (!authSession) {
      throw redirect({
        to: '/sign-in',
        search: {
          redirect: location.href,
        },
      })
    }
  },
  component: AuthenticatedComponent,
})

function AuthenticatedComponent() {
  return (
      <Outlet />
  )
}
  1. Sign in with your favourite method and redirect to the protected route on success
await signIn.email(data, {
  onSuccess: () => {
    void router.navigate({ to: '/' })
  }
})
  1. The redirect will now fail the first time and redirect me back to the sign in page because even though the API request succeeded and we only navigate in the onSuccess callback, the state of useSession did not yet update.

Current vs. Expected behavior

Current:
The state of useSession has not been updated in the onSuccess callbacks of the API functions.

Expected:
I would expect the the state to be already updated in the onSuccess callback so I can perform actions like described above

What version of Better Auth are you using?

1.1.3

Provide environment information

OS: Linux 6.12.4-arch1-1
Browser: Chrome 130.0.6723.116

Which area(s) are affected? (Select all that apply)

Client

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

No response

Originally created by @k3dom on GitHub (Dec 24, 2024). ### Is this suited for github? - [X] Yes, this is suited for github ### To Reproduce 1. Setup a Tanstack Router/Start project with a authenticated routes as recommended [here](https://tanstack.com/router/latest/docs/framework/react/guide/authenticated-routes#authentication-using-react-contexthooks) main.tsx: ```ts function App() { const { data: session } = useSession() return ( <StrictMode> <RouterProvider router={router} context={{ authSession: session?.session }} /> </StrictMode> ) } const rootElement = document.getElementById('root')! if (!rootElement.innerHTML) { createRoot(rootElement).render(<App />) } ``` _authenticated.tsx: ```ts export const Route = createFileRoute('/_authenticated')({ beforeLoad: async ({ location, context: { authSession } }) => { if (!authSession) { throw redirect({ to: '/sign-in', search: { redirect: location.href, }, }) } }, component: AuthenticatedComponent, }) function AuthenticatedComponent() { return ( <Outlet /> ) } ``` 2. Sign in with your favourite method and redirect to the protected route on success ```ts await signIn.email(data, { onSuccess: () => { void router.navigate({ to: '/' }) } }) ``` 3. The redirect will now fail the first time and redirect me back to the sign in page because even though the API request succeeded and we only navigate in the `onSuccess` callback, the state of `useSession` did not yet update. ### Current vs. Expected behavior **Current:** The state of `useSession` has not been updated in the `onSuccess` callbacks of the API functions. **Expected:** I would expect the the state to be already updated in the `onSuccess` callback so I can perform actions like described above ### What version of Better Auth are you using? 1.1.3 ### Provide environment information ```bash OS: Linux 6.12.4-arch1-1 Browser: Chrome 130.0.6723.116 ``` ### Which area(s) are affected? (Select all that apply) Client ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context _No response_
GiteaMirror added the bug label 2026-03-13 07:48:27 -05:00
GiteaMirror commented 2026-03-13 07:48:29 -05:00
Author
Owner
Copy Link

@Ooscaar commented on GitHub (Jan 3, 2025):

I think you can accomplish that by using https://www.better-auth.com/docs/concepts/session-management#get-session.

As stated in the documentation FAQ's (https://www.better-auth.com/docs/reference/faq):
image

You could do the following in _authenticated.tsx:

export const Route = createFileRoute("/_authenticated")({
  beforeLoad: async () => {
    // Check session server side
    const { data: sessionData } = await authClient.getSession();
    if (!sessionData) {
      throw redirect({ to: "/register" });
    }
  },
});

I am not 100% that is the exact correct way of doing that, but it is quite reasonable.

@Ooscaar commented on GitHub (Jan 3, 2025): I think you can accomplish that by using https://www.better-auth.com/docs/concepts/session-management#get-session. As stated in the documentation FAQ's (https://www.better-auth.com/docs/reference/faq): ![image](https://github.com/user-attachments/assets/34b52f8c-f8ab-4db7-b3a9-833b5b292fcd) You could do the following in `_authenticated.tsx`: ```typescript export const Route = createFileRoute("/_authenticated")({ beforeLoad: async () => { // Check session server side const { data: sessionData } = await authClient.getSession(); if (!sessionData) { throw redirect({ to: "/register" }); } }, }); ``` I am not 100% that is the exact correct way of doing that, but it is quite reasonable.
GiteaMirror commented 2026-03-13 07:48:29 -05:00
Author
Owner
Copy Link

@k3dom commented on GitHub (Jan 3, 2025):

This is actually what I did initially. The problem here is that it does a network request not only whenever you navigate to a site but actually 3 times when you have the default prefretch strategie enabled. This results in a pretty laggy experience

@k3dom commented on GitHub (Jan 3, 2025): This is actually what I did initially. The problem here is that it does a network request not only whenever you navigate to a site but actually 3 times when you have the default prefretch strategie enabled. This results in a pretty laggy experience
GiteaMirror commented 2026-03-13 07:48:29 -05:00
Author
Owner
Copy Link

@Ooscaar commented on GitHub (Jan 4, 2025):

Does it actually?
I am only experimenting one request on each route "protected" by the beforeLoad function with this routes folder setup:

apps/frontend/src/routes/
├── _authenticated
│   └── dashboard
│       ├── dashboard.module.css
│       └── index.tsx
├── _authenticated.tsx
@Ooscaar commented on GitHub (Jan 4, 2025): Does it actually? I am only experimenting one request on each route "protected" by the `beforeLoad` function with this routes folder setup: ``` apps/frontend/src/routes/ ├── _authenticated │   └── dashboard │   ├── dashboard.module.css │   └── index.tsx ├── _authenticated.tsx ```
GiteaMirror commented 2026-03-13 07:48:30 -05:00
Author
Owner
Copy Link

@k3dom commented on GitHub (Jan 4, 2025):

Do you have preloading enabled?

import { createRouter } from '@tanstack/react-router'

const router = createRouter({
  // ...
  defaultPreload: 'intent',
})
@k3dom commented on GitHub (Jan 4, 2025): Do you have [preloading](https://tanstack.com/router/v1/docs/framework/react/guide/preloading) enabled? ```ts import { createRouter } from '@tanstack/react-router' const router = createRouter({ // ... defaultPreload: 'intent', }) ```
GiteaMirror commented 2026-03-13 07:48:31 -05:00
Author
Owner
Copy Link

@Ooscaar commented on GitHub (Jan 4, 2025):

Aa I see.
I am using the default configuration from the docs, without using the createRouter function.

import { StrictMode } from "react";
import ReactDOM from "react-dom/client";
import { RouterProvider, createRouter } from "@tanstack/react-router";
import "./index.css";

// Import the generated route tree
import { routeTree } from "./routeTree.gen";

// Create a new router instance
const router = createRouter({ routeTree });

// Register the router instance for type safety
declare module "@tanstack/react-router" {
  interface Register {
    router: typeof router;
  }
}

// Render the app
const rootElement = document.getElementById("root")!;
if (!rootElement.innerHTML) {
  const root = ReactDOM.createRoot(rootElement);
  root.render(
    <StrictMode>
      <RouterProvider router={router} />
    </StrictMode>
  );
}

In any case, I think that for our concerns:

  • If preloading is not enabled, the usage of the function await getSession seems reasonable
  • In the case of having preloading enabled, maybe the introduction of react query could solve your problems? (in order to cache someway the auth call and prevent duplicated requests)
@Ooscaar commented on GitHub (Jan 4, 2025): Aa I see. I am using the default configuration from the docs, without using the `createRouter` function. ```typescript import { StrictMode } from "react"; import ReactDOM from "react-dom/client"; import { RouterProvider, createRouter } from "@tanstack/react-router"; import "./index.css"; // Import the generated route tree import { routeTree } from "./routeTree.gen"; // Create a new router instance const router = createRouter({ routeTree }); // Register the router instance for type safety declare module "@tanstack/react-router" { interface Register { router: typeof router; } } // Render the app const rootElement = document.getElementById("root")!; if (!rootElement.innerHTML) { const root = ReactDOM.createRoot(rootElement); root.render( <StrictMode> <RouterProvider router={router} /> </StrictMode> ); } ``` In any case, I think that for our concerns: - If preloading is not enabled, the usage of the function `await getSession` seems reasonable - In the case of having preloading enabled, maybe the introduction of react query could solve your problems? (in order to cache someway the auth call and prevent duplicated requests)
GiteaMirror commented 2026-03-13 07:48:33 -05:00
Author
Owner
Copy Link

@k3dom commented on GitHub (Jan 5, 2025):

Aa I see. I am using the default configuration from the docs, without using the createRouter function.

import { StrictMode } from "react";
import ReactDOM from "react-dom/client";
import { RouterProvider, createRouter } from "@tanstack/react-router";
import "./index.css";

// Import the generated route tree
import { routeTree } from "./routeTree.gen";

// Create a new router instance
const router = createRouter({ routeTree });

// Register the router instance for type safety
declare module "@tanstack/react-router" {
  interface Register {
    router: typeof router;
  }
}

// Render the app
const rootElement = document.getElementById("root")!;
if (!rootElement.innerHTML) {
  const root = ReactDOM.createRoot(rootElement);
  root.render(
    <StrictMode>
      <RouterProvider router={router} />
    </StrictMode>
  );
}

In any case, I think that for our concerns:

  • If preloading is not enabled, the usage of the function await getSession seems reasonable
  • In the case of having preloading enabled, maybe the introduction of react query could solve your problems? (in order to cache someway the auth call and prevent duplicated requests)

Yeah trying to cache the getSession API call with react query was another thing I tried. If I remember the main reason why I wasn't happy with that solution is that now you have the auth state in two different locations. Once in the internal better-auth atom and the query cache. This leads to code duplication. It just seems like the last solution I came up with (the one in the issue) is the cleanest as it not only uses the already existing state of better-auth, does not need to do any API requests on routing and is also the recommended way to pass state to the beforeLoad function as per the Tanstack Router docs. I also just feel like it would generally be much better and more expected for the state to be up to date in the onSuccess hook. Just seems to make semantic sense as it implies the operation to be successfully over.

@k3dom commented on GitHub (Jan 5, 2025): > Aa I see. I am using the default configuration from the docs, without using the `createRouter` function. > > ```ts > import { StrictMode } from "react"; > import ReactDOM from "react-dom/client"; > import { RouterProvider, createRouter } from "@tanstack/react-router"; > import "./index.css"; > > // Import the generated route tree > import { routeTree } from "./routeTree.gen"; > > // Create a new router instance > const router = createRouter({ routeTree }); > > // Register the router instance for type safety > declare module "@tanstack/react-router" { > interface Register { > router: typeof router; > } > } > > // Render the app > const rootElement = document.getElementById("root")!; > if (!rootElement.innerHTML) { > const root = ReactDOM.createRoot(rootElement); > root.render( > <StrictMode> > <RouterProvider router={router} /> > </StrictMode> > ); > } > ``` > > In any case, I think that for our concerns: > > * If preloading is not enabled, the usage of the function `await getSession` seems reasonable > * In the case of having preloading enabled, maybe the introduction of react query could solve your problems? (in order to cache someway the auth call and prevent duplicated requests) Yeah trying to cache the `getSession` API call with react query was another thing I tried. If I remember the main reason why I wasn't happy with that solution is that now you have the auth state in two different locations. Once in the internal better-auth atom and the query cache. This leads to code duplication. It just seems like the last solution I came up with (the one in the issue) is the cleanest as it not only uses the already existing state of better-auth, does not need to do any API requests on routing and is also the recommended way to pass state to the `beforeLoad` function as per the Tanstack Router docs. I also just feel like it would generally be much better and more expected for the state to be up to date in the `onSuccess` hook. Just seems to make semantic sense as it implies the operation to be successfully over.
GiteaMirror commented 2026-03-13 07:48:33 -05:00
Author
Owner
Copy Link

@Ooscaar commented on GitHub (Jan 5, 2025):

Yea, that makes total sense.

@Ooscaar commented on GitHub (Jan 5, 2025): Yea, that makes total sense.
GiteaMirror commented 2026-03-13 07:48:34 -05:00
Author
Owner
Copy Link

@Scooter1337 commented on GitHub (Jan 5, 2025):

Maybe the following would help your cause, I've used this myself here and there.

You can check both preload and cause in beforeLoad (cause only if you want it to check only when entering the layout, remove that otherwise to only check for preloads)
https://tanstack.com/router/latest/docs/framework/react/api/router/RouteOptionsType#beforeload-method

e.g.

beforeLoad: async ({ preload, cause, ... })
  // skip check if preloading or if we're not entering
  if ( preload || cause !== "enter" ) {
    return;
  }

  // ... check session etc.
}
@Scooter1337 commented on GitHub (Jan 5, 2025): Maybe the following would help your cause, I've used this myself here and there. You can check both `preload` and `cause` in `beforeLoad` (`cause` only if you want it to check only when entering the layout, remove that otherwise to only check for preloads) https://tanstack.com/router/latest/docs/framework/react/api/router/RouteOptionsType#beforeload-method e.g. ```typescript beforeLoad: async ({ preload, cause, ... }) // skip check if preloading or if we're not entering if ( preload || cause !== "enter" ) { return; } // ... check session etc. } ```
GiteaMirror commented 2026-03-13 07:48:35 -05:00
Author
Owner
Copy Link

@banjo commented on GitHub (Feb 8, 2025):

Interested in this as well. Currently trying to implement Better Auth with Tanstack Router and the router context. This suggestion would fix my current problem:

export const Route = createFileRoute("/_authenticated")({
  beforeLoad: async () => {
    // Check session server side
    const { data: sessionData } = await authClient.getSession();
    if (!sessionData) {
      throw redirect({ to: "/register" });
    }
  },
});

But it would always force a second call for getSession, which is not ideal. Unless you of course use react query or something similar as pointed out above.

My current logic uses useSession to get the auth state, but when signing in or out, that wont update on the first call, but have to wait for the get-session call to finish, which breaks a lot of logic.

@banjo commented on GitHub (Feb 8, 2025): Interested in this as well. Currently trying to implement Better Auth with Tanstack Router and the router context. This suggestion would fix my current problem: ``` export const Route = createFileRoute("/_authenticated")({ beforeLoad: async () => { // Check session server side const { data: sessionData } = await authClient.getSession(); if (!sessionData) { throw redirect({ to: "/register" }); } }, }); ``` But it would always force a second call for `getSession`, which is not ideal. Unless you of course use react query or something similar as pointed out above. My current logic uses `useSession` to get the auth state, but when signing in or out, that wont update on the first call, but have to wait for the `get-session` call to finish, which breaks a lot of logic.
GiteaMirror commented 2026-03-13 07:48:35 -05:00
Author
Owner
Copy Link

@amosbastian commented on GitHub (Feb 13, 2025):

I've not used better-auth yet, but have been using TanStack Router for ages and have experienced this problem in the past when trying to handle auth. My solution (hack) was to call

await new Promise((resolve) => requestAnimationFrame(() => requestAnimationFrame(resolve)));

before the navigate. Not sure if that will help you guys or not (I'll be trying out better-auth tomorrow, so will see for myself). In their basic auth example they do a different type of hack where they do an await sleep(1)

@amosbastian commented on GitHub (Feb 13, 2025): I've not used `better-auth` yet, but have been using TanStack Router for ages and have experienced this problem in the past when trying to handle auth. My solution (hack) was to call ``` await new Promise((resolve) => requestAnimationFrame(() => requestAnimationFrame(resolve))); ``` before the `navigate`. Not sure if that will help you guys or not (I'll be trying out `better-auth` tomorrow, so will see for myself). In their basic auth example they do a different type of hack where they do an `await sleep(1)`
GiteaMirror commented 2026-03-13 07:48:36 -05:00
Author
Owner
Copy Link

@ruaanetwork commented on GitHub (Feb 14, 2025):

I've not used better-auth yet, but have been using TanStack Router for ages and have experienced this problem in the past when trying to handle auth. My solution (hack) was to call

await new Promise((resolve) => requestAnimationFrame(() => requestAnimationFrame(resolve)));

before the navigate. Not sure if that will help you guys or not (I'll be trying out better-auth tomorrow, so will see for myself). In their basic auth example they do a different type of hack where they do an await sleep(1)

to prevent duplicate calls for the getSession function I followed this code from above:

Maybe the following would help your cause, I've used this myself here and there.

You can check both preload and cause in beforeLoad (cause only if you want it to check only when entering the layout, remove that otherwise to only check for preloads) https://tanstack.com/router/latest/docs/framework/react/api/router/RouteOptionsType#beforeload-method

e.g.

beforeLoad: async ({ preload, cause, ... })
// skip check if preloading or if we're not entering
if ( preload || cause !== "enter" ) {
return;
}

// ... check session etc.
}

I think it's sufficient for now, although useSession has other issues not just when used in beforeLoad function (through router context), for example, after signing in using any sign in method, when trying to display the user data in dashboard, isPending always, same as in:
https://github.com/better-auth/better-auth/issues/1006

better-auth v1.1.15

@ruaanetwork commented on GitHub (Feb 14, 2025): > I've not used `better-auth` yet, but have been using TanStack Router for ages and have experienced this problem in the past when trying to handle auth. My solution (hack) was to call > > ``` > await new Promise((resolve) => requestAnimationFrame(() => requestAnimationFrame(resolve))); > ``` > > before the `navigate`. Not sure if that will help you guys or not (I'll be trying out `better-auth` tomorrow, so will see for myself). In their basic auth example they do a different type of hack where they do an `await sleep(1)` to prevent duplicate calls for the getSession function I followed this code from above: > Maybe the following would help your cause, I've used this myself here and there. > > You can check both `preload` and `cause` in `beforeLoad` (`cause` only if you want it to check only when entering the layout, remove that otherwise to only check for preloads) https://tanstack.com/router/latest/docs/framework/react/api/router/RouteOptionsType#beforeload-method > > e.g. > > beforeLoad: async ({ preload, cause, ... }) > // skip check if preloading or if we're not entering > if ( preload || cause !== "enter" ) { > return; > } > > // ... check session etc. > } I think it's sufficient for now, although useSession has other issues not just when used in beforeLoad function (through router context), for example, after signing in using any sign in method, when trying to display the user data in dashboard, isPending always, same as in: https://github.com/better-auth/better-auth/issues/1006 better-auth v1.1.15
GiteaMirror commented 2026-03-13 07:48:36 -05:00
Author
Owner
Copy Link

@gaboe commented on GitHub (Jun 24, 2025):

Using "better-auth": "1.2.10" and "@tanstack/react-start": "1.121.26"

Nothing helped, until i have moved logic here to react component and did this "old way"

✅

import { createFileRoute, Outlet, useNavigate } from "@tanstack/react-router";
import { useSession } from "@/lib/auth-client";
import { useEffect } from "react";

export const Route = createFileRoute("/_auth")({
  component: AuthLayout,
});

function AuthLayout() {
  const navigate = useNavigate();
  const { data: session, isPending } = useSession();
  const user = session?.user;

  useEffect(() => {
    console.log("[_auth] user", user, isPending);
    if (!user && !isPending) {
      console.log("[_auth] redirecting to /sign-in");
      navigate({ to: "/sign-in", replace: true });
    }
  }, [user, isPending, navigate]);

  //   if (isPending) {
  //     return null;
  //   }

  return (
    <div>
      <Outlet />
    </div>
  );
}

I would excpect, this would work
❌

import { createFileRoute, redirect, Outlet } from "@tanstack/react-router";
import { getSession } from "@/lib/auth-client";

export const Route = createFileRoute("/_auth")({
  beforeLoad: async ({ location }) => {
    const session = await getSession();
    if (!session?.data?.user) {
      throw redirect({
        to: "/sign-in",
        search: { redirect: location.href },
      });
    }
  },
  component: AuthLayout,
});

function AuthLayout() {
  return (
    <div>
      <Outlet />
    </div>
  );
}
@gaboe commented on GitHub (Jun 24, 2025): Using "better-auth": "1.2.10" and "@tanstack/react-start": "1.121.26" Nothing helped, until i have moved logic here to react component and did this "old way" ✅ ```typescript import { createFileRoute, Outlet, useNavigate } from "@tanstack/react-router"; import { useSession } from "@/lib/auth-client"; import { useEffect } from "react"; export const Route = createFileRoute("/_auth")({ component: AuthLayout, }); function AuthLayout() { const navigate = useNavigate(); const { data: session, isPending } = useSession(); const user = session?.user; useEffect(() => { console.log("[_auth] user", user, isPending); if (!user && !isPending) { console.log("[_auth] redirecting to /sign-in"); navigate({ to: "/sign-in", replace: true }); } }, [user, isPending, navigate]); // if (isPending) { // return null; // } return ( <div> <Outlet /> </div> ); } ``` I would excpect, this would work ❌ ```typescript import { createFileRoute, redirect, Outlet } from "@tanstack/react-router"; import { getSession } from "@/lib/auth-client"; export const Route = createFileRoute("/_auth")({ beforeLoad: async ({ location }) => { const session = await getSession(); if (!session?.data?.user) { throw redirect({ to: "/sign-in", search: { redirect: location.href }, }); } }, component: AuthLayout, }); function AuthLayout() { return ( <div> <Outlet /> </div> ); } ```
GiteaMirror commented 2026-03-13 07:48:37 -05:00
Author
Owner
Copy Link

@gaboe commented on GitHub (Jun 26, 2025):

I was able to resolve it by fetching the session server-side in the root route and passing it down via context. This ensures the session is always up-to-date before any protected route logic runs, avoiding the race condition between sign-in and redirect.

Solution:
In __root.tsx (or your root route), fetch the session using your server-side auth method (e.g., getServerSession) in the beforeLoad and return it in the context:

export const Route = createRootRouteWithContext<...>()({
  beforeLoad: async () => {
    const session = await getServerSession();
    return { session };
  },
  // ...
});

Then, in your protected route (e.g., _auth.tsx), you can safely check for the session in beforeLoad:

export const Route = createFileRoute("/_auth")({
  beforeLoad: ({ context: { session } }) => {
    if (!session?.user) {
      throw redirect({ to: "/sign-in" });
    }
  },
  // ...
});

This approach ensures the session is always current and avoids the redirect loop after sign-in.

@gaboe commented on GitHub (Jun 26, 2025): I was able to resolve it by fetching the session server-side in the root route and passing it down via context. This ensures the session is always up-to-date before any protected route logic runs, avoiding the race condition between sign-in and redirect. **Solution:** In `__root.tsx` (or your root route), fetch the session using your server-side auth method (e.g., `getServerSession`) in the `beforeLoad` and return it in the context: ```ts export const Route = createRootRouteWithContext<...>()({ beforeLoad: async () => { const session = await getServerSession(); return { session }; }, // ... }); ``` Then, in your protected route (e.g., `_auth.tsx`), you can safely check for the session in `beforeLoad`: ```ts export const Route = createFileRoute("/_auth")({ beforeLoad: ({ context: { session } }) => { if (!session?.user) { throw redirect({ to: "/sign-in" }); } }, // ... }); ``` This approach ensures the session is always current and avoids the redirect loop after sign-in.
GiteaMirror commented 2026-03-13 07:48:37 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 25, 2025):

Hi, @kedom1337. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported that after signing in with Better Auth 1.1.3, the useSession state does not update immediately in the onSuccess callback, causing routing issues.
  • Workarounds discussed include using getSession in beforeLoad, but this can cause multiple network requests, especially with preloading enabled.
  • A robust solution I proposed and implemented involves fetching the session server-side in the root route's beforeLoad and passing it via context.
  • This approach avoids race conditions and ensures the session state is current before protected route logic runs.
  • Additional improvements include checking preload and cause in beforeLoad to reduce redundant calls and handling redirects within React component effects.

Next Steps:

  • Please confirm if this solution still applies to the latest version of better-auth and if you continue to experience any related issues.
  • If this issue is no longer relevant, it will be automatically closed in 7 days unless you comment to keep it open.

Thanks for your understanding and contribution!

@dosubot[bot] commented on GitHub (Sep 25, 2025): Hi, @kedom1337. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that after signing in with Better Auth 1.1.3, the `useSession` state does not update immediately in the `onSuccess` callback, causing routing issues. - Workarounds discussed include using `getSession` in `beforeLoad`, but this can cause multiple network requests, especially with preloading enabled. - A robust solution I proposed and implemented involves fetching the session server-side in the root route's `beforeLoad` and passing it via context. - This approach avoids race conditions and ensures the session state is current before protected route logic runs. - Additional improvements include checking `preload` and `cause` in `beforeLoad` to reduce redundant calls and handling redirects within React component effects. **Next Steps:** - Please confirm if this solution still applies to the latest version of better-auth and if you continue to experience any related issues. - If this issue is no longer relevant, it will be automatically closed in 7 days unless you comment to keep it open. Thanks for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#463
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?