github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-13 16:32:26 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #2178] Nuxt SSR Warning with better-auth useSession(useFetch) #9085

New Issue
Closed
opened 2026-04-13 04:23:25 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-13 04:23:25 -05:00
Owner
Copy Link

Originally created by @cwandev on GitHub (Apr 8, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2178

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Initialize a new Nuxt 4 project.

  2. Install better-auth.

  3. Configure better-auth according to the documentation, setting up the necessary server plugin/API routes and the client-side plugin (authClient).

  4. In any page component that runs during SSR (e.g., app/pages/index.vue), import authClient and Nuxt's useFetch, then call authClient.useSession like this:

    <script setup lang="ts">
import { authClient } from '@/lib/auth-client'; // Adjust path if needed
import { useFetch } from '#app';

// Fetch the session using the better-auth client and Nuxt's useFetch
const { data: session, error } = await authClient.useSession(useFetch);

// Optional: Log to see the result, though the warning appears regardless
// console.log('Session data:', session.value);
// console.log('Fetch error:', error.value);
</script>

<template>
  <div>
    <!-- Your page content -->
    <pre v-if="session">Session: {{ session }}</pre>
    <pre v-else-if="error">Error: {{ error }}</pre>
    <p v-else>Loading session...</p>
  </div>
</template>

  5. Ensure SSR is enabled (which is the default in Nuxt 4).

  6. Run the Nuxt development server (e.g., npm run dev or pnpm dev).

  7. Check the terminal output where the Nuxt server logs are displayed. You should see the SSR warning related to useFetch returning undefined.

Current vs. Expected behavior

Current behavior:

During SSR, using authClient.useSession(useFetch) triggers the following Nuxt warning in the server console:

ssr:warn [nuxt] `useFetch` must return a value (it should not be `undefined`) or the request may be duplicated on the client side.

This suggests a potential issue with SSR data handling for this specific fetch call.

Expected behavior:

The authClient.useSession(useFetch) call should execute during SSR without triggering any Nuxt warnings about undefined return values. The integration should work smoothly without suggesting potential duplicate client-side requests.

What version of Better Auth are you using?

1.2.5

Provide environment information

- OS: macOS Sequoia 15.4
- Browser: Chrome 135
- Nuxt version: 3.16.2
- Node.js version: 20.12.2

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

Package

Auth config (if applicable)

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

Additional context

We have looked into the better-auth source code for the useSession client implementation, specifically for the Vue/Nuxt integration:
https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/client/vue/index.ts

Based on the code, it appears that when Nuxt's useFetch is provided, the function handles the returned Promise correctly and explicitly returns an object like { data, isPending, error } within the .then() callback. It doesn't seem to directly return undefined in this code path.

Despite this, the Nuxt SSR warning persists. Our hypothesis is that the warning might arise from a more subtle interaction between Nuxt's internal useFetch handling (particularly its SSR data deduplication logic) and the specific way better-auth invokes it. This could potentially be related to the ref option being passed internally to useFetch:

return useFetch(`${authPath}/get-session`, {
  ref: useStore(pluginsAtoms.$sessionSignal), // Possible interaction point?
}).then(...)

The issue seems specifically tied to the server-side rendering phase, as the warning originates from ssr:warn [nuxt].

Originally created by @cwandev on GitHub (Apr 8, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2178 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1. Initialize a new Nuxt 4 project. 2. Install `better-auth`. 3. Configure `better-auth` according to the documentation, setting up the necessary server plugin/API routes and the client-side plugin (`authClient`). 4. In any page component that runs during SSR (e.g., `app/pages/index.vue`), import `authClient` and Nuxt's `useFetch`, then call `authClient.useSession` like this: ```vue <script setup lang="ts"> import { authClient } from '@/lib/auth-client'; // Adjust path if needed import { useFetch } from '#app'; // Fetch the session using the better-auth client and Nuxt's useFetch const { data: session, error } = await authClient.useSession(useFetch); // Optional: Log to see the result, though the warning appears regardless // console.log('Session data:', session.value); // console.log('Fetch error:', error.value); </script> <template> <div> <!-- Your page content --> <pre v-if="session">Session: {{ session }}</pre> <pre v-else-if="error">Error: {{ error }}</pre> <p v-else>Loading session...</p> </div> </template> ``` 5. Ensure SSR is enabled (which is the default in Nuxt 4). 6. Run the Nuxt development server (e.g., `npm run dev` or `pnpm dev`). 7. Check the terminal output where the Nuxt server logs are displayed. You should see the SSR warning related to `useFetch` returning `undefined`. ### Current vs. Expected behavior **Current behavior:** During SSR, using `authClient.useSession(useFetch)` triggers the following Nuxt warning in the server console: ```log ssr:warn [nuxt] `useFetch` must return a value (it should not be `undefined`) or the request may be duplicated on the client side. ``` This suggests a potential issue with SSR data handling for this specific fetch call. **Expected behavior:** The `authClient.useSession(useFetch)` call should execute during SSR without triggering any Nuxt warnings about `undefined` return values. The integration should work smoothly without suggesting potential duplicate client-side requests. ### What version of Better Auth are you using? 1.2.5 ### Provide environment information ```bash - OS: macOS Sequoia 15.4 - Browser: Chrome 135 - Nuxt version: 3.16.2 - Node.js version: 20.12.2 ``` ### Which area(s) are affected? (Select all that apply) Package ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context We have looked into the `better-auth` source code for the `useSession` client implementation, specifically for the Vue/Nuxt integration: [https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/client/vue/index.ts](https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/client/vue/index.ts) Based on the code, it appears that when Nuxt's `useFetch` is provided, the function handles the returned Promise correctly and explicitly returns an object like `{ data, isPending, error }` within the `.then()` callback. It doesn't seem to directly return `undefined` in this code path. Despite this, the Nuxt SSR warning persists. Our hypothesis is that the warning might arise from a more subtle interaction between Nuxt's internal `useFetch` handling (particularly its SSR data deduplication logic) and the specific way `better-auth` invokes it. This could potentially be related to the `ref` option being passed internally to `useFetch`: ```typescript return useFetch(`${authPath}/get-session`, { ref: useStore(pluginsAtoms.$sessionSignal), // Possible interaction point? }).then(...) ``` The issue seems specifically tied to the server-side rendering phase, as the warning originates from `ssr:warn [nuxt]`.
GiteaMirror added the locked label 2026-04-13 04:23:25 -05:00
GiteaMirror commented 2026-04-13 04:23:27 -05:00
Author
Owner
Copy Link

@Mateleo commented on GitHub (Apr 10, 2025):

Did you find a solution ? @CharleeWa

<!-- gh-comment-id:2792332892 --> @Mateleo commented on GitHub (Apr 10, 2025): Did you find a solution ? @CharleeWa
GiteaMirror commented 2026-04-13 04:23:27 -05:00
Author
Owner
Copy Link

@yooouuri commented on GitHub (Apr 11, 2025):

@CharleeWa

Image

I tried to remove the ref: useStore(pluginsAtoms.$sessionSignal), didn't do anything...

Don't know what's wrong, but is completely broken.

<!-- gh-comment-id:2795909725 --> @yooouuri commented on GitHub (Apr 11, 2025): @CharleeWa <img width="692" alt="Image" src="https://github.com/user-attachments/assets/4c86ce95-af80-48dd-9d88-8ea021faf16a" /> I tried to remove the `ref: useStore(pluginsAtoms.$sessionSignal)`, didn't do anything... Don't know what's wrong, but is completely broken.
GiteaMirror commented 2026-04-13 04:23:28 -05:00
Author
Owner
Copy Link

@cwandev commented on GitHub (Apr 11, 2025):

Did you find a solution ? @CharleeWa

Thank you for your attention to this issue; unfortunately, we haven't made progress as our focus has shifted to business development priorities for now.

<!-- gh-comment-id:2796647441 --> @cwandev commented on GitHub (Apr 11, 2025): > Did you find a solution ? [@CharleeWa](https://github.com/CharleeWa) Thank you for your attention to this issue; unfortunately, we haven't made progress as our focus has shifted to business development priorities for now.
GiteaMirror commented 2026-04-13 04:23:29 -05:00
Author
Owner
Copy Link

@yooouuri commented on GitHub (Apr 18, 2025):

@CharleeWa when I am not logged in (I don't have a cookie)

Image Image

https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/api/routes/session.ts#L89-L91

https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/api/routes/session.ts#L157-L168

It returns empty json, and I think useFetch is not able to parse that correct

<!-- gh-comment-id:2815269325 --> @yooouuri commented on GitHub (Apr 18, 2025): @CharleeWa when I am not logged in (I don't have a cookie) <img width="588" alt="Image" src="https://github.com/user-attachments/assets/4a7efb00-065a-4db9-8283-f94e03c4211c" /> <img width="533" alt="Image" src="https://github.com/user-attachments/assets/b940885f-ec0b-4acc-9e34-924adad496db" /> https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/api/routes/session.ts#L89-L91 https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/api/routes/session.ts#L157-L168 It returns empty json, and I think useFetch is not able to parse that correct
GiteaMirror commented 2026-04-13 04:23:30 -05:00
Author
Owner
Copy Link

@Mateleo commented on GitHub (Apr 18, 2025):

@yooouuri This worked for me https://github.com/better-auth/better-auth/issues/1707#issuecomment-2752071258

<!-- gh-comment-id:2815398571 --> @Mateleo commented on GitHub (Apr 18, 2025): @yooouuri This worked for me https://github.com/better-auth/better-auth/issues/1707#issuecomment-2752071258
GiteaMirror commented 2026-04-13 04:23:31 -05:00
Author
Owner
Copy Link

@cwandev commented on GitHub (Apr 18, 2025):

@yooouuri Just now I tested it: it correctly returns null when not logged in; after logging in, it only makes one server-side request, and the ssr:warn in the console is gone.

Image Image

Edit: I tested Better Auth versions 1.2.5, 1.2.6, and 1.2.7 — the warning disappeared in all of them. Not sure why it suddenly started working; none of the patches seem to explicitly fix it.

<!-- gh-comment-id:2815716183 --> @cwandev commented on GitHub (Apr 18, 2025): @yooouuri Just now I tested it: it correctly returns null when not logged in; after logging in, it only makes one server-side request, and the `ssr:warn` in the console is gone. <img width="735" alt="Image" src="https://github.com/user-attachments/assets/88c8d8a3-5b23-4b0a-baf8-99fb900a2959" /> <img width="735" alt="Image" src="https://github.com/user-attachments/assets/6dee286c-160a-4eb6-b0c6-e195051c8235" /> Edit: I tested Better Auth versions 1.2.5, 1.2.6, and 1.2.7 — the warning disappeared in all of them. Not sure why it suddenly started working; none of the patches seem to explicitly fix it.
GiteaMirror commented 2026-04-13 04:23:31 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (May 5, 2025):

I think this was related to we not returning null. Now that's fixed, I think this is no longer an issue. Feel free to re-open of this is still the case.

<!-- gh-comment-id:2852190937 --> @Bekacru commented on GitHub (May 5, 2025): I think this was related to we not returning `null`. Now that's fixed, I think this is no longer an issue. Feel free to re-open of this is still the case.
GiteaMirror commented 2026-04-13 04:23:32 -05:00
Author
Owner
Copy Link

@moshetanzer commented on GitHub (May 5, 2025):

This is correct - won’t be warning anymore ❤️

<!-- gh-comment-id:2852200591 --> @moshetanzer commented on GitHub (May 5, 2025): This is correct - won’t be warning anymore ❤️
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 locked
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#9085
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?