github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 15:42:09 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #522] Session ID Type Conflict and Unexpected Database Query on Secondary Storage Cache Clear #8305

New Issue
Closed
opened 2026-04-13 03:22:46 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-13 03:22:46 -05:00
Owner
Copy Link

Originally created by @wh5938316 on GitHub (Nov 14, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/522

Describe the bug
When enabling Secondary storage in better-auth, session IDs default to nanoid, even when database.generateId is set to uuid or false. This setup works as expected, but an issue arises if the Secondary storage (e.g., Redis) is cleared. In this case, better-auth makes a request to the session table in the primary database. If PostgreSQL is used with session.id as a UUID type, it raises a type error due to invalid UUID input syntax, for instance:

invalid input syntax for type uuid: "QvkAB7iB9Qd4w1GnD31lIpJxH0yYQqcn"

After enabling Secondary storage, I noticed that sessions are not stored in the primary database. If making a query to the session table is intended, it seems incorrect that no session record is found in the table after login. If the absence of session records in the primary database after login is expected behavior, better-auth should not attempt to query the database when the session record is missing from Secondary storage.

Expected behavior

  1. If querying the session table in the primary database is intentional, the session should persist in the database after login.
  2. If session persistence in the primary database is not expected after login, better-auth should avoid querying the database when no session record is found in Secondary storage.

Thank you for looking into this!

Originally created by @wh5938316 on GitHub (Nov 14, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/522 **Describe the bug** When enabling Secondary storage in better-auth, session IDs default to nanoid, even when `database.generateId` is set to uuid or false. This setup works as expected, but an issue arises if the Secondary storage (e.g., Redis) is cleared. In this case, better-auth makes a request to the session table in the primary database. If PostgreSQL is used with `session.id` as a UUID type, it raises a type error due to invalid UUID input syntax, for instance: ``` invalid input syntax for type uuid: "QvkAB7iB9Qd4w1GnD31lIpJxH0yYQqcn" ``` After enabling Secondary storage, I noticed that sessions are not stored in the primary database. If making a query to the session table is intended, it seems incorrect that no session record is found in the table after login. If the absence of session records in the primary database after login is expected behavior, better-auth should not attempt to query the database when the session record is missing from Secondary storage. **Expected behavior** 1. If querying the session table in the primary database is intentional, the session should persist in the database after login. 2. If session persistence in the primary database is not expected after login, better-auth should avoid querying the database when no session record is found in Secondary storage. Thank you for looking into this!
GiteaMirror added the locked label 2026-04-13 03:22:46 -05:00
GiteaMirror commented 2026-04-13 03:22:47 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Nov 26, 2024):

I don't think this is an issue anymore since we're doing the lookup by "token" instead. Feel free to reopen if you think it's still applicable. And looking up the db as a fallback makes sense, so if you enable secondary storage at some point, all the existing db-stored sessions won't return null

<!-- gh-comment-id:2501786152 --> @Bekacru commented on GitHub (Nov 26, 2024): I don't think this is an issue anymore since we're doing the lookup by "token" instead. Feel free to reopen if you think it's still applicable. And looking up the db as a fallback makes sense, so if you enable secondary storage at some point, all the existing db-stored sessions won't return null
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#8305
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?