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

[GH-ISSUE #7877] getSession() does not update useSession() reactive state (Vue) #19567

New Issue
Closed
opened 2026-04-15 18:49:18 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-15 18:49:18 -05:00
Owner
Copy Link

Originally created by @hartbit on GitHub (Feb 9, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7877

Is this suited for github?

  • Yes, this is suited for github

Reproduction

Minimal repo: https://github.com/hartbit/better-auth-usesession-bug

git clone https://github.com/hartbit/better-auth-usesession-bug
cd better-auth-usesession-bug
npm install
npm run dev
  1. Open http://localhost:5173 and sign up with the pre-filled credentials.
  2. Enter a new name and click "Update name (without workaround)".
  3. The greeting still shows the old name.

The name is updated server-side via a custom Express endpoint (using auth.api.updateUser), then the client calls authClient.getSession() to re-fetch the session. The network request succeeds and returns the updated data, but useSession() does not reflect the change.

Current vs. Expected behavior

Current: After calling getSession(), the value returned by useSession() still contains stale data. The internal session atom is not updated with the fresh response.

Expected: getSession() should update the session atom so that all useSession() subscribers reactively reflect the new session data.

Workaround

Manually setting the atom in the onSuccess callback:

await authClient.getSession({
  fetchOptions: {
    throw: true,
    onSuccess: (ctx) => {
      authClient.$store.atoms.session?.set({
        ...authClient.$store.atoms.session.get(),
        data: ctx.data,
        isPending: false,
        isRefetching: false,
      });
    },
  },
});

Related

This is related to #1006 but is a distinct issue: it's not about the initial session fetch race condition, but about getSession() consistently failing to propagate updated data to useSession() subscribers after a server-side mutation.

Environment

  • better-auth: 1.4.18
  • Vue 3.5 + Vite
  • Node 22
Originally created by @hartbit on GitHub (Feb 9, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7877 ### Is this suited for github? - [X] Yes, this is suited for github ### Reproduction Minimal repo: https://github.com/hartbit/better-auth-usesession-bug ```bash git clone https://github.com/hartbit/better-auth-usesession-bug cd better-auth-usesession-bug npm install npm run dev ``` 1. Open http://localhost:5173 and sign up with the pre-filled credentials. 2. Enter a new name and click **"Update name (without workaround)"**. 3. The greeting still shows the old name. The name is updated server-side via a custom Express endpoint (using `auth.api.updateUser`), then the client calls `authClient.getSession()` to re-fetch the session. The network request succeeds and returns the updated data, but `useSession()` does not reflect the change. ### Current vs. Expected behavior **Current:** After calling `getSession()`, the value returned by `useSession()` still contains stale data. The internal session atom is not updated with the fresh response. **Expected:** `getSession()` should update the session atom so that all `useSession()` subscribers reactively reflect the new session data. ### Workaround Manually setting the atom in the `onSuccess` callback: ```ts await authClient.getSession({ fetchOptions: { throw: true, onSuccess: (ctx) => { authClient.$store.atoms.session?.set({ ...authClient.$store.atoms.session.get(), data: ctx.data, isPending: false, isRefetching: false, }); }, }, }); ``` ### Related This is related to #1006 but is a distinct issue: it's not about the initial session fetch race condition, but about `getSession()` consistently failing to propagate updated data to `useSession()` subscribers after a server-side mutation. ### Environment - better-auth: 1.4.18 - Vue 3.5 + Vite - Node 22
GiteaMirror added the locked label 2026-04-15 18:49:18 -05:00
GiteaMirror commented 2026-04-15 18:49:21 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Feb 9, 2026):

It looks like you're experiencing an issue where getSession() does not update the reactive state of useSession() in your Vue setup.

From the information provided, this appears to be a known concern where getSession() fails to propagate updated session data to useSession() subscribers even after a successful network request. You mentioned a workaround that involves manually setting the atom in the onSuccess callback, which is a common approach for such scenarios when automatic propagation doesn't occur.

For further steps, I would recommend:

  1. Consider implementing your workaround in your application as it effectively updates the session atom.
  2. Keep an eye on related issues, particularly the one you referenced (#1006), to see if further improvements or fixes are scheduled in upcoming releases.

If you want more detailed assistance or have other questions, feel free to tag @bekacru or @ping__ from the Better Auth team! Is there a specific part of the session handling that you're looking to improve or debug further?

If you need more help, tag @better-auth-agent in a comment so I can respond.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3872193559 --> @better-auth-agent[bot] commented on GitHub (Feb 9, 2026): It looks like you're experiencing an issue where `getSession()` does not update the reactive state of `useSession()` in your Vue setup. From the information provided, this appears to be a known concern where `getSession()` fails to propagate updated session data to `useSession()` subscribers even after a successful network request. You mentioned a workaround that involves manually setting the atom in the `onSuccess` callback, which is a common approach for such scenarios when automatic propagation doesn't occur. For further steps, I would recommend: 1. Consider implementing your workaround in your application as it effectively updates the session atom. 2. Keep an eye on related issues, particularly the one you referenced (#1006), to see if further improvements or fixes are scheduled in upcoming releases. If you want more detailed assistance or have other questions, feel free to tag @bekacru or @ping__ from the Better Auth team! Is there a specific part of the session handling that you're looking to improve or debug further? _If you need more help, tag @better-auth-agent in a comment so I can respond._ <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-15 18:49:23 -05:00
Author
Owner
Copy Link

@hartbit commented on GitHub (Feb 9, 2026):

@ping-maxwell You asked in #1006 for people to open new issues. I've done so here with a reproduction example. If you test it, you will see that calling getSession after a server side session update will GET /auth/get-session but that useSession refs don't get updated.

<!-- gh-comment-id:3872225088 --> @hartbit commented on GitHub (Feb 9, 2026): @ping-maxwell You asked in #1006 for people to open new issues. I've done so here with a reproduction example. If you test it, you will see that calling `getSession` after a server side session update will `GET /auth/get-session` but that `useSession` refs don't get updated.
GiteaMirror commented 2026-04-15 18:49:24 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Feb 10, 2026):

Updating the session on the server-side will not trigger auth-client refreshes since the auth-client has no way of knowing that the session has updated.

To mitigate this, we've implemented polling features on auth-client's specifically for the react (@better-auth/react) package, however this feature is not implemented yet on other framework clients.

This certainly is something we are looking to get implemented in the future though!

<!-- gh-comment-id:3875409955 --> @ping-maxwell commented on GitHub (Feb 10, 2026): Updating the session on the server-side will not trigger auth-client refreshes since the auth-client has no way of knowing that the session has updated. To mitigate this, we've implemented polling features on auth-client's specifically for the react (`@better-auth/react`) package, however this feature is not implemented yet on other framework clients. This certainly is something we are looking to get implemented in the future though!
GiteaMirror commented 2026-04-15 18:49:24 -05:00
Author
Owner
Copy Link

@hartbit commented on GitHub (Feb 10, 2026):

@ping-maxwell I understand that updating the session server-side will not trigger auth-client refresh. That's why in my repro I manually call getSession after the server-side change. The problem is that the getSession call causes a GET /auth/get-session with the updated data but the useSession refs don't get updated. That's the real issue for me.

<!-- gh-comment-id:3876147970 --> @hartbit commented on GitHub (Feb 10, 2026): @ping-maxwell I understand that updating the session server-side will not trigger auth-client refresh. That's why in my repro I manually call `getSession` **after** the server-side change. The problem is that the `getSession` call causes a `GET /auth/get-session` with the updated data but the `useSession` refs don't get updated. That's the real issue for me.
GiteaMirror commented 2026-04-15 18:49:25 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Feb 15, 2026):

getSession call by itself also doesn't trigger useSession. The useSession hook depends on paths to determine to update itself or not. If it starts re-rendering on /get-session it'll not cause recursion loop. We can technically try to prevent this but you should use refresh from use-session hook.

<!-- gh-comment-id:3903210980 --> @Bekacru commented on GitHub (Feb 15, 2026): getSession call by itself also doesn't trigger useSession. The `useSession` hook depends on paths to determine to update itself or not. If it starts re-rendering on `/get-session` it'll not cause recursion loop. We can technically try to prevent this but you should use `refresh` from use-session hook.
GiteaMirror commented 2026-04-15 18:49:26 -05:00
Author
Owner
Copy Link

@hartbit commented on GitHub (Feb 18, 2026):

@Bekacru I understand. But the workaround I mentioned relies on knowledge of implementation details of the Better Auth client. Do you have a better workaround ? Isn't Better Auth missing a function to get an updated session and update useSession refs ? Something like getSession({ refreshRefs: true }) ?

<!-- gh-comment-id:3920905417 --> @hartbit commented on GitHub (Feb 18, 2026): @Bekacru I understand. But the workaround I mentioned relies on knowledge of implementation details of the Better Auth client. Do you have a better workaround ? Isn't Better Auth missing a function to get an updated session and update `useSession` refs ? Something like `getSession({ refreshRefs: true })` ?
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#19567
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?