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 #87] React: signin does not trigger the session atom refresh #25443

New Issue
Closed
opened 2026-04-17 15:39:19 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-17 15:39:19 -05:00
Owner
Copy Link

Originally created by @paulgirard on GitHub (Oct 4, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/87

We are testing your library for a small tool.
We like very much the approach, thanks for creating and sharing that lib 🙏

We are using it with react client-side (and tsoa server side) and we've just discovered that a successful call to signin.email does not trigger the session atom refresh action.
The signOut does.

I am surprised by such a behavior as I understood that the useSession should be the only source of truth.

By reading the source code I think this behavior is due to those lines:

const atomListeners: AtomListener[] = [
		{
			signal: "_sessionSignal",
			matcher(path) {
				return (
					path === "/sign-out" ||
					path === "sign-up/email" ||
					path === "/user/update"
				);
			},
		},
	];

https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/client/config.ts#L36-L38

Looks like the only API calls which trigger a session refresh are sign-out, sign-up and user/update.
But I am not sure I understood the codebase correctly?

Is that in purpose that sign-in is not in that list?
If yes could someone explain the rational behind this choice?
If not should I propose a PR to add it?

Originally created by @paulgirard on GitHub (Oct 4, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/87 We are testing your library for a small tool. We like very much the approach, thanks for creating and sharing that lib :pray: We are using it with react client-side (and tsoa server side) and we've just discovered that a successful call to signin.email does not trigger the session atom refresh action. The signOut does. I am surprised by such a behavior as I understood that the useSession should be the only source of truth. By reading the source code I think this behavior is due to those lines: ```typescript const atomListeners: AtomListener[] = [ { signal: "_sessionSignal", matcher(path) { return ( path === "/sign-out" || path === "sign-up/email" || path === "/user/update" ); }, }, ]; ``` https://github.com/better-auth/better-auth/blob/main/packages/better-auth/src/client/config.ts#L36-L38 Looks like the only API calls which trigger a session refresh are `sign-out`, `sign-up` and `user/update`. But I am not sure I understood the codebase correctly? Is that in purpose that sign-in is not in that list? If yes could someone explain the rational behind this choice? If not should I propose a PR to add it?
GiteaMirror added the locked label 2026-04-17 15:39:19 -05:00
GiteaMirror commented 2026-04-17 15:39:21 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Oct 4, 2024):

Oh, 'sign-in' wasn't added, assuming there would be a redirection. It should definitely be there, and yes, feel free to open a PR. I would appreciate that!

<!-- gh-comment-id:2394077791 --> @Bekacru commented on GitHub (Oct 4, 2024): Oh, 'sign-in' wasn't added, assuming there would be a redirection. It should definitely be there, and yes, feel free to open a PR. I would appreciate that!
GiteaMirror commented 2026-04-17 15:39:23 -05:00
Author
Owner
Copy Link

@paulgirard commented on GitHub (Oct 4, 2024):

Thanks for your very prompt reply.
I'll propose a PR beginning of next week as I am out for the week end.
Thanks again for your work

<!-- gh-comment-id:2394094434 --> @paulgirard commented on GitHub (Oct 4, 2024): Thanks for your very prompt reply. I'll propose a PR beginning of next week as I am out for the week end. Thanks again for your work
GiteaMirror commented 2026-04-17 15:39:23 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Oct 4, 2024):

Thanks for your very prompt reply. I'll propose a PR beginning of next week as I am out for the week end. Thanks again for your work

No worries. It should be added on the next release.

<!-- gh-comment-id:2394099464 --> @Bekacru commented on GitHub (Oct 4, 2024): > Thanks for your very prompt reply. I'll propose a PR beginning of next week as I am out for the week end. Thanks again for your work No worries. It should be added on the next release.
GiteaMirror commented 2026-04-17 15:39:25 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Oct 4, 2024):

fixed on latest

<!-- gh-comment-id:2394274466 --> @Bekacru commented on GitHub (Oct 4, 2024): fixed on latest
GiteaMirror commented 2026-04-17 15:39:25 -05:00
Author
Owner
Copy Link

@paulgirard commented on GitHub (Oct 7, 2024):

I confirm that fixed the issue! Thank you.

<!-- gh-comment-id:2397155204 --> @paulgirard commented on GitHub (Oct 7, 2024): I confirm that fixed the issue! Thank you.
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#25443
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?