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

[GH-ISSUE #2303] Multiple possible bugs associated with page reload (SolidStart and Postgresql) #9138

New Issue
Closed
opened 2026-04-13 04:29:26 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-13 04:29:26 -05:00
Owner
Copy Link

Originally created by @Garrett-Floyd on GitHub (Apr 15, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2303

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Go to https://github.com/Garrett-Floyd/better_auth_error and read reproduceBugInstructions.txt for a description of the current vs Expected behavior and the steps to reproduce. The contents is reproduced for convenience below:

Possible Bug 1: When signing up and signing in users using server api,
session info is not updated until page is manually refreshed.
This is the case even when redirecting upon (sign in/sign up).
When using client api this isn't a problem.

Possible Bug 2: On manual page reload but not using hyperlinks the session cookie isn't
always avaliable fast enough to be used in building the page.
You can usually get session info fast enough if your using it in app.tsx (the root file in solidstart apps).
However, if your using session infor in apps.tsx's props.children than the data may or may not be avaliable.
This is especially an issue when on page load you fetch via GET request to some protected route.
In my experience when this is done the session cookie is essentially never avaliable fast enough and the request is denied.
I would like to redirect to login on when an user is not signed in and they try to access a protected resource and
this bug makes that unfeasable.

To reproduce the reported behavior take the following steps:

  1. Recreate the project in the repository by copying it and use commands given in ./commandLineBuildSteps.txt.

  2. Sign up a least one account using dummy info.

  3. Play around with the different sign up, sign in, forms given in ./src/routes/index.tsx and ./src/routes/sign-up.tsx
    to compare behavior signing in and up using client vs server api. This should reveal the behavior for possible bug 1.

  4. On sign in I have the app redirect to test.tsx. If you manually refresh test.tsx
    (this includes redirect to the page using the client side sign in api)
    sometimes the component won't display the user name In the welcome agian (username here)! message.
    This only happens for components/routes that are in props.children of app.tsx,
    if its used directly or in a component that used directly in app.tsx
    the username seems to always display correctly as in the first welcome (username here)! message.
    The fetch request to the protected route should always fail.
    I have the protected route print out the headers it recieves from the request and
    If you examine them you should see that their are no cookies sent with the request.
    I also have the the client print out the session info onMount and
    it is avaliable and correct even though it wasn't for the purposes of the GET request.
    Interestling enough if you use the hyperlink to return to login and then use the hyperlink to return to test then
    the session info is avaliable for the messages and the GET request.

Current vs. Expected behavior

Go to https://github.com/Garrett-Floyd/better_auth_error and read reproduceBugInstructions.txt for a description of the current vs Expected behavior and the steps to reproduce. The contents is reproduced for convenience below:

Possible Bug 1: When signing up and signing in users using server api,
session info is not updated until page is manually refreshed.
This is the case even when redirecting upon (sign in/sign up).
When using client api this isn't a problem.

Possible Bug 2: On manual page reload but not using hyperlinks the session cookie isn't
always avaliable fast enough to be used in building the page.
You can usually get session info fast enough if your using it in app.tsx (the root file in solidstart apps).
However, if your using session infor in apps.tsx's props.children than the data may or may not be avaliable.
This is especially an issue when on page load you fetch via GET request to some protected route.
In my experience when this is done the session cookie is essentially never avaliable fast enough and the request is denied.
I would like to redirect to login on when an user is not signed in and they try to access a protected resource and
this bug makes that unfeasable.

To reproduce the reported behavior take the following steps:

  1. Recreate the project in the repository by copying it and use commands given in ./commandLineBuildSteps.txt.

  2. Sign up a least one account using dummy info.

  3. Play around with the different sign up, sign in, forms given in ./src/routes/index.tsx and ./src/routes/sign-up.tsx
    to compare behavior signing in and up using client vs server api. This should reveal the behavior for possible bug 1.

  4. On sign in I have the app redirect to test.tsx. If you manually refresh test.tsx
    (this includes redirect to the page using the client side sign in api)
    sometimes the component won't display the user name In the welcome agian (username here)! message.
    This only happens for components/routes that are in props.children of app.tsx,
    if its used directly or in a component that used directly in app.tsx
    the username seems to always display correctly as in the first welcome (username here)! message.
    The fetch request to the protected route should always fail.
    I have the protected route print out the headers it recieves from the request and
    If you examine them you should see that their are no cookies sent with the request.
    I also have the the client print out the session info onMount and
    it is avaliable and correct even though it wasn't for the purposes of the GET request.
    Interestling enough if you use the hyperlink to return to login and then use the hyperlink to return to test then
    the session info is avaliable for the messages and the GET request.

What version of Better Auth are you using?

1.2.7

Provide environment information

- OS: Microsoft Windows 11 HOME version: 10.0.26100 Build 26100
- browser: chrome

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

Backend, Client

Auth config (if applicable)

import { betterAuth } from "better-auth";
import { pool } from "./pool";
 
export const auth = betterAuth({
  database: pool,
  emailAndPassword: { enabled: true },
  // postgres is already using user as a table name.
  // changing name to users allows us to inspect the table.
  user: {
    modelName: "users",
  },
})

Additional context

No response

Originally created by @Garrett-Floyd on GitHub (Apr 15, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2303 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Go to https://github.com/Garrett-Floyd/better_auth_error and read reproduceBugInstructions.txt for a description of the current vs Expected behavior and the steps to reproduce. The contents is reproduced for convenience below: Possible Bug 1: When signing up and signing in users using server api, session info is not updated until page is manually refreshed. This is the case even when redirecting upon (sign in/sign up). When using client api this isn't a problem. Possible Bug 2: On manual page reload but not using hyperlinks the session cookie isn't always avaliable fast enough to be used in building the page. You can usually get session info fast enough if your using it in app.tsx (the root file in solidstart apps). However, if your using session infor in apps.tsx's props.children than the data may or may not be avaliable. This is especially an issue when on page load you fetch via GET request to some protected route. In my experience when this is done the session cookie is essentially never avaliable fast enough and the request is denied. I would like to redirect to login on when an user is not signed in and they try to access a protected resource and this bug makes that unfeasable. To reproduce the reported behavior take the following steps: 1. Recreate the project in the repository by copying it and use commands given in ./commandLineBuildSteps.txt. 2. Sign up a least one account using dummy info. 3. Play around with the different sign up, sign in, forms given in ./src/routes/index.tsx and ./src/routes/sign-up.tsx to compare behavior signing in and up using client vs server api. This should reveal the behavior for possible bug 1. 4. On sign in I have the app redirect to test.tsx. If you manually refresh test.tsx (this includes redirect to the page using the client side sign in api) sometimes the component won't display the user name In the welcome agian (username here)! message. This only happens for components/routes that are in props.children of app.tsx, if its used directly or in a component that used directly in app.tsx the username seems to always display correctly as in the first welcome (username here)! message. The fetch request to the protected route should always fail. I have the protected route print out the headers it recieves from the request and If you examine them you should see that their are no cookies sent with the request. I also have the the client print out the session info onMount and it is avaliable and correct even though it wasn't for the purposes of the GET request. Interestling enough if you use the hyperlink to return to login and then use the hyperlink to return to test then the session info is avaliable for the messages and the GET request. ### Current vs. Expected behavior Go to https://github.com/Garrett-Floyd/better_auth_error and read reproduceBugInstructions.txt for a description of the current vs Expected behavior and the steps to reproduce. The contents is reproduced for convenience below: Possible Bug 1: When signing up and signing in users using server api, session info is not updated until page is manually refreshed. This is the case even when redirecting upon (sign in/sign up). When using client api this isn't a problem. Possible Bug 2: On manual page reload but not using hyperlinks the session cookie isn't always avaliable fast enough to be used in building the page. You can usually get session info fast enough if your using it in app.tsx (the root file in solidstart apps). However, if your using session infor in apps.tsx's props.children than the data may or may not be avaliable. This is especially an issue when on page load you fetch via GET request to some protected route. In my experience when this is done the session cookie is essentially never avaliable fast enough and the request is denied. I would like to redirect to login on when an user is not signed in and they try to access a protected resource and this bug makes that unfeasable. To reproduce the reported behavior take the following steps: 1. Recreate the project in the repository by copying it and use commands given in ./commandLineBuildSteps.txt. 2. Sign up a least one account using dummy info. 3. Play around with the different sign up, sign in, forms given in ./src/routes/index.tsx and ./src/routes/sign-up.tsx to compare behavior signing in and up using client vs server api. This should reveal the behavior for possible bug 1. 4. On sign in I have the app redirect to test.tsx. If you manually refresh test.tsx (this includes redirect to the page using the client side sign in api) sometimes the component won't display the user name In the welcome agian (username here)! message. This only happens for components/routes that are in props.children of app.tsx, if its used directly or in a component that used directly in app.tsx the username seems to always display correctly as in the first welcome (username here)! message. The fetch request to the protected route should always fail. I have the protected route print out the headers it recieves from the request and If you examine them you should see that their are no cookies sent with the request. I also have the the client print out the session info onMount and it is avaliable and correct even though it wasn't for the purposes of the GET request. Interestling enough if you use the hyperlink to return to login and then use the hyperlink to return to test then the session info is avaliable for the messages and the GET request. ### What version of Better Auth are you using? 1.2.7 ### Provide environment information ```bash - OS: Microsoft Windows 11 HOME version: 10.0.26100 Build 26100 - browser: chrome ``` ### Which area(s) are affected? (Select all that apply) Backend, Client ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth"; import { pool } from "./pool"; export const auth = betterAuth({ database: pool, emailAndPassword: { enabled: true }, // postgres is already using user as a table name. // changing name to users allows us to inspect the table. user: { modelName: "users", }, }) ``` ### Additional context _No response_
GiteaMirror added the lockedbug labels 2026-04-13 04:29:26 -05:00
GiteaMirror commented 2026-04-13 04:29:28 -05:00
Author
Owner
Copy Link

@Garrett-Floyd commented on GitHub (Apr 15, 2025):

Sorry to possibly put multiple bugs in the same request, but I'm not entirely sure they're not actually different faces of the same issue.

<!-- gh-comment-id:2807467202 --> @Garrett-Floyd commented on GitHub (Apr 15, 2025): Sorry to possibly put multiple bugs in the same request, but I'm not entirely sure they're not actually different faces of the same issue.
GiteaMirror commented 2026-04-13 04:29:28 -05:00
Author
Owner
Copy Link

@Garrett-Floyd commented on GitHub (Apr 20, 2025):

Update. I've found that if you pass the headers from solid's getRequestEvent().request.headers to the fetch request it is able to get the data from the protected route on the initial rendering. I'm not sure exactly why this works, maybe since the initial render is on the server it's valid to call getRequestEvent() there as it returns undefined on the client. I also found that when you switch from the default ssr mode to spa mode it's also able to get the data regardless of whether you manually pass the headers or not.

<!-- gh-comment-id:2817341732 --> @Garrett-Floyd commented on GitHub (Apr 20, 2025): Update. I've found that if you pass the headers from solid's getRequestEvent().request.headers to the fetch request it is able to get the data from the protected route on the initial rendering. I'm not sure exactly why this works, maybe since the initial render is on the server it's valid to call getRequestEvent() there as it returns undefined on the client. I also found that when you switch from the default ssr mode to spa mode it's also able to get the data regardless of whether you manually pass the headers or not.
GiteaMirror commented 2026-04-13 04:29:29 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 20, 2025):

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

Issue Summary

  • Two potential bugs reported related to session handling in SolidStart with PostgreSQL.
  • Issues involve session information not updating until a manual refresh and session cookies not being available quickly enough.
  • You suggested a workaround by passing headers to fetch requests, resolving the issue during initial server-side rendering.
  • Switching to spa mode also resolves the problem.

Next Steps

  • Is this issue still relevant to the latest version of the better-auth repository? If so, please comment to keep the discussion open.
  • Otherwise, this issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

<!-- gh-comment-id:3094620374 --> @dosubot[bot] commented on GitHub (Jul 20, 2025): Hi, @Garrett-Floyd. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog. I'm marking this issue as stale. **Issue Summary** - Two potential bugs reported related to session handling in SolidStart with PostgreSQL. - Issues involve session information not updating until a manual refresh and session cookies not being available quickly enough. - You suggested a workaround by passing headers to fetch requests, resolving the issue during initial server-side rendering. - Switching to spa mode also resolves the problem. **Next Steps** - Is this issue still relevant to the latest version of the better-auth repository? If so, please comment to keep the discussion open. - Otherwise, this issue will be automatically closed in 7 days. Thank you 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 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#9138
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?