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

useSession causes hundreds/thousands of duplicate requests under slow network + react async server component hydration #1907

New Issue
Closed
opened 2026-03-13 09:11:56 -05:00 by GiteaMirror · 12 comments
GiteaMirror commented 2026-03-13 09:11:56 -05:00
Owner
Copy Link

Originally created by @SorooshGb on GitHub (Sep 12, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

No, this is not some bad React code that is causing infinite re-renders or something 😄

I narrowed the problem down to this reproducible scenario in my own Next.js app:

  1. Create a Next.js app and set up Better Auth with minimal configuration.
  2. Create a Navbar client component that calls the useSession hook. (Just calling the hook is enough.)
  3. Use the Navbar in the root layout.tsx. (Must be in a top layout)
  4. Create a new page.tsx (or use the top-level page.tsx). Make this page component an async function. (Must be async)

    You don’t need to await anything inside — simply declaring it as async is enough to trigger the issue.

  5. Inside this page, render a medium-sized client component. (This is very important)

    If the component is too small, the bug doesn’t trigger. A “safe” reproduction size is ~200 lines of code with a few UI library components imported.

  6. Open Chrome DevTools → Network tab, and throttle speed to 3G.
  7. Check “Disable cache” in the Network tab. (This often makes the issue reliably reproduce.)
  8. Load the page.
  9. Watch the network panel — you will see /api/auth/get-session requests piling up (hundreds to thousands and sometimes even more).

Important conditions

For this issue to occur, all three of the following conditions must be met:

  • A slow network connection (e.g., 3G throttling)
  • Disable cache checked in Chrome DevTools (often required in the minimal repro)
  • A useSession call inside a client component used in the top layout
  • A page component declared as async (even with no await inside)
  • A relatively mediums sized client component rendered inside that async page (if the component is too small, the issue does not trigger)

Current vs. Expected behavior

Expected Behavior

  • useSession should fire once (or at most once per component mount).

Current Behavior

  • useSession triggers /api/auth/get-session 600–1800 times, depending on component size and network speed.
  • In some cases, especially in production mode with heavier code, I observed tens of thousands of requests continuously being sent and piling up until the page fully loads.

Minimal Repro Repository

This repo consistently reproduces the issue. In this lighter setup, the bug appears more consistently when Disable cache is checked in Chrome DevTools (Network tab) while throttling to 3G.

Image

What version of Better Auth are you using?

1.3.9

System info

{
  "system": {
    "platform": "win32",
    "arch": "x64",
    "version": "Windows 11 Home",
    "release": "10.0.26100",
    "cpuCount": 12,
    "cpuModel": "13th Gen Intel(R) Core(TM) i5-13420H",
    "totalMemory": "31.73 GB",
    "freeMemory": "15.26 GB"
  },
  "node": {
    "version": "v22.16.0",
    "env": "development"
  },
  "packageManager": {
    "name": "npm",
    "version": "11.4.2"
  },
  "frameworks": [
    {
      "name": "next",
      "version": "15.4.2"
    },
    {
      "name": "react",
      "version": "19.1.0"
    }
  ],
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    },
    {
      "name": "drizzle",
      "version": "^0.44.3"
    }
  ],
  "betterAuth": {
    "version": "0.1.0",
    "config": null
  }
}

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

Client

Auth config (if applicable)

import { createAuthClient } from 'better-auth/react';
import { inferAdditionalFields } from 'better-auth/client/plugins';
import { auth } from './auth';

export const { signIn, signOut, signUp, useSession } = createAuthClient({
  plugins: [inferAdditionalFields<typeof auth>()],
});

Additional context

Additional Context

  • Reproduced with useSession alone — no extra fetch calls in render.
  • If the fetch is wrapped in useEffect or gated with a useIsMounted check, the problem disappears.
  • I also tested by adding a simple console.log('hello') or a test fetch('https://jsonplaceholder.typicode.com/todos/1') call:
    • When wrapped in useEffect, they fire once as expected.
    • When placed inline in a client component used in the root layout, they fire hundreds of times under the same conditions.
  • This shows the behavior is tied to Next.js/React async server components and hydration process.
  • Normally, developers don’t put fetches inline (they always use useEffect), so most apps won’t hit this scenario.
  • However, useSession internally kicks off a fetch as soon as it mounts, so Better Auth should take this seriously and ensure that fetch calls only happen after hydration somehow.
  • This happens in both dev and production builds (as long as the page is not cached in production).
  • From testing, this does not happen when useSession is called in a normal client component.
    It only happens when useSession is called in a client component used in the layout, combined with a route that has an async page server component.

Temporary Workaround

  • Wrap the entire navbar (or any useSession caller) in a hydration guard (useIsMounted) that sets the isMounted state to true in a useEffect, and render the component with the useSession only when isMounted is true.
Originally created by @SorooshGb on GitHub (Sep 12, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce No, this is not some bad React code that is causing infinite re-renders or something 😄 I narrowed the problem down to this reproducible scenario in my own Next.js app: 1. Create a **Next.js** app and set up Better Auth with minimal configuration. 2. Create a `Navbar` client component that calls the `useSession` hook. (Just calling the hook is enough.) 3. Use the `Navbar` in the root `layout.tsx`. (Must be in a top layout) 4. Create a new `page.tsx` (or use the top-level `page.tsx`). Make this page component an **async function**. (Must be async) > You don’t need to `await` anything inside — simply declaring it as `async` is enough to trigger the issue. 5. Inside this page, render a **medium-sized client component**. (This is very important) > If the component is too small, the bug doesn’t trigger. A “safe” reproduction size is ~200 lines of code with a few UI library components imported. 6. Open Chrome DevTools → **Network** tab, and throttle speed to **3G**. 7. **Check “Disable cache”** in the Network tab. (This often makes the issue reliably reproduce.) 8. Load the page. 9. Watch the network panel — you will see `/api/auth/get-session` requests piling up (hundreds to thousands and sometimes even more). ### Important conditions For this issue to occur, all three of the following conditions must be met: - A **slow network connection** (e.g., 3G throttling) - **Disable cache** checked in Chrome DevTools (often required in the minimal repro) - A `useSession` call inside a **client component used in the top layout** - A **page component declared as async** (even with no `await` inside) - A **relatively mediums sized client component rendered inside that async page** (if the component is too small, the issue does not trigger) ### Current vs. Expected behavior ## Expected Behavior - `useSession` should fire **once** (or at most once per component mount). ## Current Behavior - `useSession` triggers `/api/auth/get-session` **600–1800 times**, depending on component size and network speed. - In some cases, especially in production mode with heavier code, I observed **tens of thousands of requests** continuously being sent and piling up until the page fully loads. ## Minimal Repro Repository - https://github.com/SorooshGb/better-auth-test2 > This repo consistently reproduces the issue. In this lighter setup, the bug appears more consistently when **Disable cache** is checked in Chrome DevTools (Network tab) while throttling to **3G**. <img width="1919" height="914" alt="Image" src="https://github.com/user-attachments/assets/504db9b3-3d22-4ff5-a9a7-838bf322cb7d" /> ### What version of Better Auth are you using? 1.3.9 ### System info ```bash { "system": { "platform": "win32", "arch": "x64", "version": "Windows 11 Home", "release": "10.0.26100", "cpuCount": 12, "cpuModel": "13th Gen Intel(R) Core(TM) i5-13420H", "totalMemory": "31.73 GB", "freeMemory": "15.26 GB" }, "node": { "version": "v22.16.0", "env": "development" }, "packageManager": { "name": "npm", "version": "11.4.2" }, "frameworks": [ { "name": "next", "version": "15.4.2" }, { "name": "react", "version": "19.1.0" } ], "databases": [ { "name": "pg", "version": "^8.16.3" }, { "name": "drizzle", "version": "^0.44.3" } ], "betterAuth": { "version": "0.1.0", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Client ### Auth config (if applicable) ```typescript import { createAuthClient } from 'better-auth/react'; import { inferAdditionalFields } from 'better-auth/client/plugins'; import { auth } from './auth'; export const { signIn, signOut, signUp, useSession } = createAuthClient({ plugins: [inferAdditionalFields<typeof auth>()], }); ``` ### Additional context ## Additional Context - Reproduced with `useSession` alone — no extra fetch calls in render. - If the fetch is wrapped in `useEffect` or gated with a `useIsMounted` check, the problem disappears. - I also tested by adding a simple `console.log('hello')` or a test `fetch('https://jsonplaceholder.typicode.com/todos/1')` call: - When wrapped in `useEffect`, they fire **once** as expected. - When placed inline in a client component used in the root layout, they fire **hundreds of times** under the same conditions. - This shows the behavior is tied to Next.js/React async server components and hydration process. - Normally, developers don’t put fetches inline (they always use `useEffect`), so most apps won’t hit this scenario. - However, `useSession` internally kicks off a fetch as soon as it mounts, so Better Auth should take this seriously and ensure that fetch calls only happen after hydration somehow. - This happens in both **dev** and **production** builds (as long as the page is not cached in production). - From testing, this **does not happen** when `useSession` is called in a normal client component. It only happens when `useSession` is called in a client component used in the **layout**, combined with a route that has an **async page server component**. ## Temporary Workaround - Wrap the entire navbar (or any `useSession` caller) in a hydration guard (`useIsMounted`) that sets the `isMounted` state to `true` in a `useEffect`, and render the component with the `useSession` only when `isMounted` is `true`.
GiteaMirror added the nextjsbug labels 2026-03-13 09:11:56 -05:00
GiteaMirror commented 2026-03-13 09:11:59 -05:00
Author
Owner
Copy Link

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

This is a known issue with Better Auth's useSession hook in Next.js apps, especially when used in client components inside layouts combined with async server components. The root cause is that useSession triggers fetches immediately on mount, relying on a reactive store rather than useEffect, which can lead to hundreds or thousands of duplicate requests during hydration under slow network and disabled cache conditions. This behavior is tied to how React and Next.js handle hydration and client/server boundaries, not to infinite re-renders or bad code.

A recommended workaround is to wrap your useSession calls (such as in your Navbar) in a hydration guard (like useIsMounted) so the hook only runs after the component is mounted. For a more robust solution, consider using a Provider pattern at the root of your app to pass initial session data from the server, which prevents redundant fetches and maintains SSR compatibility. You can see details and example code for this approach in this GitHub issue.

No recent changes in Better Auth directly address this problem, so using a hydration guard or Provider is currently the best way to avoid duplicate requests.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Sep 12, 2025): <!-- Answer --> This is a known issue with Better Auth's useSession hook in Next.js apps, especially when used in client components inside layouts combined with async server components. The root cause is that useSession triggers fetches immediately on mount, relying on a reactive store rather than useEffect, which can lead to hundreds or thousands of duplicate requests during hydration under slow network and disabled cache conditions. This behavior is tied to how React and Next.js handle hydration and client/server boundaries, not to infinite re-renders or bad code. A recommended workaround is to wrap your useSession calls (such as in your Navbar) in a hydration guard (like useIsMounted) so the hook only runs after the component is mounted. For a more robust solution, consider using a Provider pattern at the root of your app to pass initial session data from the server, which prevents redundant fetches and maintains SSR compatibility. You can see details and example code for this approach in [this GitHub issue](https://github.com/better-auth/better-auth/issues/2768). No recent changes in Better Auth directly address this problem, so using a hydration guard or Provider is currently the best way to avoid duplicate requests. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/fbfdefe7-d0db-4003-ab20-6d43974da2f1?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/fbfdefe7-d0db-4003-ab20-6d43974da2f1?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/fbfdefe7-d0db-4003-ab20-6d43974da2f1?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/fbfdefe7-d0db-4003-ab20-6d43974da2f1?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/fbfdefe7-d0db-4003-ab20-6d43974da2f1?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/fbfdefe7-d0db-4003-ab20-6d43974da2f1?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/fbfdefe7-d0db-4003-ab20-6d43974da2f1?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/4609)
GiteaMirror commented 2026-03-13 09:12:00 -05:00
Author
Owner
Copy Link

@SorooshGb commented on GitHub (Sep 12, 2025):

I quickly made this wrapper useSession hook and provider to work around the issue (based on the bot’s answer).
So far it seems to be working fine — I’ll update this if I hit any problems.

SessionProvider.tsx

'use client';

import { AuthClientSession, useBetterAuthSession } from '@/features/auth/auth-client';
import React, {
  createContext,
  useContext,
  useEffect,
  useState,
  ReactNode,
  useCallback,
} from 'react';
import { useIsMounted } from './useIsMounted';

type AuthSession = typeof AuthClientSession;

type SessionContextType = {
  isPending: boolean;
  data: AuthSession | null;
};

const SessionContext = createContext<SessionContextType | null>(null);

export function SessionProvider({ children }: { children: ReactNode }) {
  const [isPending, setIsPending] = useState(true);
  const [data, setData] = useState<AuthSession | null>(null);
  const isMounted = useIsMounted();

  const onUpdate = useCallback((pending: boolean, nextData: AuthSession | null) => {
    setIsPending(pending);
    setData(nextData);
  }, []);

  return (
    <SessionContext value={{ isPending, data }}>
      {children}
      {isMounted && <SessionBridge onUpdate={onUpdate} />}
    </SessionContext>
  );
}

function SessionBridge({
  onUpdate,
}: {
  onUpdate: (isPending: boolean, data: AuthSession | null) => void;
}) {
  const { isPending: betterAuthIsPending, data: betterAuthData } = useBetterAuthSession();

  useEffect(() => {
    onUpdate(betterAuthIsPending, betterAuthData ?? null);
  }, [betterAuthIsPending, betterAuthData, onUpdate]);

  return null;
}

export function useSession() {
  const context = useContext(SessionContext);
  if (!context) throw new Error('useSession must be used within a SessionProvider');
  return context;
}

auth-client.ts

import { createAuthClient } from 'better-auth/react';

export const {
  signIn,
  signOut,
  signUp,
  useSession: useBetterAuthSession,
  $Infer: { Session: AuthClientSession },
} = createAuthClient({
  plugins: [inferAdditionalFields<typeof auth>()],
});

useIsMounted.tsx

import { useEffect, useState } from 'react';

export function useIsMounted() {
  const [isMounted, setIsMounted] = useState(false);

  useEffect(() => {
    setIsMounted(true);
  }, []);

  return isMounted;
}

I just wrap my entire app with SessionProvider in the root layout, and then replaced every call to the original useSession with my own useSession (from the provider). This way the hook is only subscribed once (after hydration), and the rest of the app consumes it safely via context.

@SorooshGb commented on GitHub (Sep 12, 2025): I quickly made this wrapper `useSession` hook and provider to work around the issue (based on the bot’s answer). So far it seems to be working fine — I’ll update this if I hit any problems. ### `SessionProvider.tsx` ```typescript 'use client'; import { AuthClientSession, useBetterAuthSession } from '@/features/auth/auth-client'; import React, { createContext, useContext, useEffect, useState, ReactNode, useCallback, } from 'react'; import { useIsMounted } from './useIsMounted'; type AuthSession = typeof AuthClientSession; type SessionContextType = { isPending: boolean; data: AuthSession | null; }; const SessionContext = createContext<SessionContextType | null>(null); export function SessionProvider({ children }: { children: ReactNode }) { const [isPending, setIsPending] = useState(true); const [data, setData] = useState<AuthSession | null>(null); const isMounted = useIsMounted(); const onUpdate = useCallback((pending: boolean, nextData: AuthSession | null) => { setIsPending(pending); setData(nextData); }, []); return ( <SessionContext value={{ isPending, data }}> {children} {isMounted && <SessionBridge onUpdate={onUpdate} />} </SessionContext> ); } function SessionBridge({ onUpdate, }: { onUpdate: (isPending: boolean, data: AuthSession | null) => void; }) { const { isPending: betterAuthIsPending, data: betterAuthData } = useBetterAuthSession(); useEffect(() => { onUpdate(betterAuthIsPending, betterAuthData ?? null); }, [betterAuthIsPending, betterAuthData, onUpdate]); return null; } export function useSession() { const context = useContext(SessionContext); if (!context) throw new Error('useSession must be used within a SessionProvider'); return context; } ``` ### `auth-client.ts` ```typescript import { createAuthClient } from 'better-auth/react'; export const { signIn, signOut, signUp, useSession: useBetterAuthSession, $Infer: { Session: AuthClientSession }, } = createAuthClient({ plugins: [inferAdditionalFields<typeof auth>()], }); ``` ### `useIsMounted.tsx` ```typescript import { useEffect, useState } from 'react'; export function useIsMounted() { const [isMounted, setIsMounted] = useState(false); useEffect(() => { setIsMounted(true); }, []); return isMounted; } ``` --- I just wrap my **entire app** with `SessionProvider` in the root layout, and then replaced every call to the original `useSession` with my own `useSession` (from the provider). This way the hook is only subscribed once (after hydration), and the rest of the app consumes it safely via context.
GiteaMirror commented 2026-03-13 09:12:01 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Sep 14, 2025):

@SorooshGb I tried to reproduce the issue using the repo you provided but i am not seeing the issue.

Image
@frectonz commented on GitHub (Sep 14, 2025): @SorooshGb I tried to reproduce the issue using the repo you provided but i am not seeing the issue. <img width="1710" height="613" alt="Image" src="https://github.com/user-attachments/assets/838aa7a6-4cc3-46e3-843c-f7d3aa347707" />
GiteaMirror commented 2026-03-13 09:12:02 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Sep 14, 2025):

Are you facing this problem only on the useSession fetch hook or does it exist on other fetch hooks like useActiveMember from the organization plugin?

@frectonz commented on GitHub (Sep 14, 2025): Are you facing this problem only on the `useSession` fetch hook or does it exist on other fetch hooks like `useActiveMember` from the organization plugin?
GiteaMirror commented 2026-03-13 09:12:02 -05:00
Author
Owner
Copy Link

@SorooshGb commented on GitHub (Sep 14, 2025):

@frectonz Please read my full explanation carefully — I’ve outlined everything you need to know.

Based on the screenshot you shared, it looks like you haven’t set the network throttling to 3G, as I mentioned.
(Keep "Disable cache" checked — you’ve done that correctly.)

The issue doesn’t occur for me either on faster network speeds, but that doesn’t mean it’s not there —
it just might not show up under those conditions.

This is definitely a Next.js/React hydration issue that's causing the fetch call to fire multiple times, from what I understand.
As I explained earlier, you can try fetching any other resource — or even just add a simple console.log('Hello') directly in the navbar (which is in a layout and is a client component, with the logic inlined — not inside a useEffect). Then, throttle the network to 3G and load an async component that renders a heavy client component. You’ll see that the fetch or log runs dozens or even thousands of times.

Obviously, we don’t want that for fetch calls. Normally, fetch calls are done inside client components using useEffect, which runs after hydration, so this issue is avoided automatically.
However, since better-auth's useSession has no hydration guard or does not run inside a useEffect, it immediately triggers the fetch before hydration completes, leading to the repeated calls.

@SorooshGb commented on GitHub (Sep 14, 2025): @frectonz Please read my full explanation carefully — I’ve outlined everything you need to know. Based on the screenshot you shared, it looks like you haven’t set the network throttling to **3G**, as I mentioned. (Keep **"Disable cache"** checked — you’ve done that correctly.) The issue doesn’t occur for me either on faster network speeds, but that doesn’t mean it’s not there — it just might not show up under those conditions. This is definitely a **Next.js/React hydration** issue that's causing the fetch call to fire multiple times, from what I understand. As I explained earlier, you can try fetching any other resource — or even just add a simple `console.log('Hello')` directly in the **navbar** (which is in a layout and is a **client component**, with the logic inlined — not inside a `useEffect`). Then, throttle the network to **3G** and load an **async component** that renders a heavy client component. You’ll see that the fetch or log runs **dozens or even thousands of times**. Obviously, we don’t want that for fetch calls. Normally, fetch calls are done inside client components using `useEffect`, which runs **after hydration**, so this issue is avoided automatically. However, since `better-auth`'s `useSession` has **no hydration guard** or does **not** run inside a `useEffect`, it immediately triggers the fetch **before hydration completes**, leading to the repeated calls.
GiteaMirror commented 2026-03-13 09:12:04 -05:00
Author
Owner
Copy Link

@SorooshGb commented on GitHub (Sep 14, 2025):

Are you facing this problem only on the useSession fetch hook or does it exist on other fetch hooks like useActiveMember from the organization plugin?

I haven’t tried using any other hooks from better-auth yet. But the underlying issue is that these aren’t actually real React hooks — they just follow the React hook naming conventions. Under the hood, they’re simply connected to nanostore, so they behave differently from true React hooks.

I think that’s why these weird behaviors — especially in the context of server-side rendering and React hydration — are showing up for people.

Just like the bot pointed out, the issue is this:

The root cause is that useSession triggers fetches immediately on mount, relying on a reactive store rather than useEffect, which can lead to hundreds or thousands of duplicate requests during hydration under slow network and disabled cache conditions.

@SorooshGb commented on GitHub (Sep 14, 2025): > Are you facing this problem only on the `useSession` fetch hook or does it exist on other fetch hooks like `useActiveMember` from the organization plugin? I haven’t tried using any other hooks from `better-auth` yet. But the underlying issue is that these aren’t actually real React hooks — they just follow the React hook naming conventions. Under the hood, they’re simply connected to **nanostore**, so they behave differently from true React hooks. I think that’s why these weird behaviors — especially in the context of **server-side rendering** and **React hydration** — are showing up for people. Just like the bot pointed out, the issue is this: > The root cause is that `useSession` triggers fetches immediately on mount, relying on a reactive store rather than `useEffect`, which can lead to hundreds or thousands of duplicate requests during hydration under slow network and disabled cache conditions.
GiteaMirror commented 2026-03-13 09:12:06 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Sep 14, 2025):

I used 3G throttling in this but didn't see the issue you described.

https://github.com/user-attachments/assets/241f69fd-55a7-4609-9270-811e58f4c3bf

Better Auth doesn't require useEffect to execute the fetch it uses nanostores to manage reactivity.

@frectonz commented on GitHub (Sep 14, 2025): I used `3G` throttling in this but didn't see the issue you described. https://github.com/user-attachments/assets/241f69fd-55a7-4609-9270-811e58f4c3bf Better Auth doesn't require `useEffect` to execute the fetch it uses [nanostores](https://github.com/nanostores/nanostores) to manage reactivity.
GiteaMirror commented 2026-03-13 09:12:06 -05:00
Author
Owner
Copy Link

@SorooshGb commented on GitHub (Sep 14, 2025):

The duplicate requests are also mentioned by this person in SSR scenarios: issue

I tested the repo I provided here again, and strangely it did not reproduce the issue this time in development mode, however when I built the app npm run build and ran npm start it happened again as you see in the video. Maybe try building and running it to see if it the issue is reproduced, thanks.

https://github.com/user-attachments/assets/96f222d5-c7a7-4987-b5fd-3aa90d30a54d

@SorooshGb commented on GitHub (Sep 14, 2025): The duplicate requests are also mentioned by this person in SSR scenarios: [issue](https://github.com/better-auth/better-auth/issues/2768#issue-3087621252) I tested the repo I provided here again, and strangely it did not reproduce the issue this time in development mode, however when I built the app `npm run build` and ran `npm start` it happened again as you see in the video. Maybe try building and running it to see if it the issue is reproduced, thanks. https://github.com/user-attachments/assets/96f222d5-c7a7-4987-b5fd-3aa90d30a54d
GiteaMirror commented 2026-03-13 09:12:07 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Sep 14, 2025):

#2768 is unrelated to this issue, their use case is different. They want to be able to pass the session information to the useSession hook so that it doesn't have to call get-session on the client.

I will try running it with the production build.

@frectonz commented on GitHub (Sep 14, 2025): #2768 is unrelated to this issue, their use case is different. They want to be able to pass the session information to the useSession hook so that it doesn't have to call `get-session` on the client. I will try running it with the production build.
GiteaMirror commented 2026-03-13 09:12:08 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Sep 14, 2025):

I can see the issue in the production build. I will investigate the issue further.

Image
@frectonz commented on GitHub (Sep 14, 2025): I can see the issue in the production build. I will investigate the issue further. <img width="1710" height="616" alt="Image" src="https://github.com/user-attachments/assets/aabb65ca-3fc1-4a7d-b1d3-1787b36bdc88" />
GiteaMirror commented 2026-03-13 09:12:09 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Sep 15, 2025):

can you checkout #4669 and make sure the bug has been fixed.

npm i https://pkg.pr.new/better-auth/better-auth@4669
@frectonz commented on GitHub (Sep 15, 2025): can you checkout #4669 and make sure the bug has been fixed. ``` npm i https://pkg.pr.new/better-auth/better-auth@4669 ```
GiteaMirror commented 2026-03-13 09:12:09 -05:00
Author
Owner
Copy Link

@SorooshGb commented on GitHub (Sep 15, 2025):

I tested it in both dev and production across three different browsers and the issue looks completely resolved.

Yesterday I also checked on Firefox — there the bug only triggered up to 2 repeated requests instead of thousands — but that case also seems fully fixed now.

Thank you and great job! 🫡

@SorooshGb commented on GitHub (Sep 15, 2025): I tested it in both dev and production across three different browsers and the issue looks completely resolved. Yesterday I also checked on Firefox — there the bug only triggered up to 2 repeated requests instead of thousands — but that case also seems fully fixed now. Thank you and great job! 🫡
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 nextjs
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#1907
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?