BetterAuth 1.2.12: Still tries to use token field in sessions table and does not generate id for session #1469

Closed
opened 2026-03-13 08:41:56 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @ivarsmas on GitHub (Jul 6, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Bug Description

After upgrading to BetterAuth 1.2.12 and following the new mapping guidelines, BetterAuth still tries to use the token field in the sessions table, even though the mapping is set to use id as the session identifier. If I add the token field as a workaround, BetterAuth then fails to generate a value for the id field, resulting in a null value in column "id" of relation "sessions" violates not-null constraint error.

Steps to Reproduce

  1. Use the following mapping in the BetterAuth config:
session: {
  modelName: "sessions",
  fields: {
    id: "id",
    userId: "user_id",
    expiresAt: "expires_at",
    createdAt: "created_at",
    updatedAt: "updated_at",
    ipAddress: "ipAddress",
    userAgent: "userAgent"
  }
},
advanced: {
  database: {
    generateId: true,
    // Also tried with generateId: false
    // Also tried with and without session: { idField: "id" }
  }
}
  1. The sessions table schema is:
CREATE TABLE public.sessions (
    id character varying(255) NOT NULL,
    user_id integer NOT NULL,
    expires_at timestamp with time zone NOT NULL,
    created_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP,
    updated_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP,
    "ipAddress" character varying(255),
    "userAgent" character varying(255)
);
  1. Call auth.api.signInEmail({ body: { email, password }, ... }) in the login endpoint.

Current vs. Expected behavior

Expected Behavior

  • BetterAuth should use the id field as the session identifier and generate a value for it automatically (when generateId: true).
  • No reference to a token field in the sessions table should be made.

Actual Behavior

  • If the token field does not exist in the sessions table, BetterAuth throws:
    error: column "token" of relation "sessions" does not exist
  • If I add the token field as a workaround, BetterAuth then throws:
    error: null value in column "id" of relation "sessions" violates not-null constraint
  • The id field is not being generated/populated.

What version of Better Auth are you using?

1.2.12

Provide environment information

## Additional Info

- Version: better-auth@1.2.12
- Node: v20.17.0
- Database: PostgreSQL (Neon)
- Next.js: v15.2.4
- The mapping is correct and matches the docs and changelog for 1.2.10+.
- I have tried cleaning node_modules, lockfile, and .next cache.
- No other config files or overrides exist.

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

Backend, Client

Auth config (if applicable)

session: {
  modelName: "sessions",
  fields: {
    id: "id",
    userId: "user_id",
    expiresAt: "expires_at",
    createdAt: "created_at",
    updatedAt: "updated_at",
    ipAddress: "ipAddress",
    userAgent: "userAgent"
  }
},
advanced: {
  database: {
    generateId: true,
    // Also tried with generateId: false
    // Also tried with and without session: { idField: "id" }
  }
}

Additional context

Impact

  • Login and session creation are completely broken with the new mapping.
  • Downgrading to previous versions works only if the token field is present, but then logout/session management is broken.

Request

  • Please clarify if there is a workaround, or fix the session creation logic to respect the mapping and generate the id as documented.

Thank you!

Originally created by @ivarsmas on GitHub (Jul 6, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce ## Bug Description After upgrading to BetterAuth 1.2.12 and following the new mapping guidelines, BetterAuth still tries to use the `token` field in the `sessions` table, even though the mapping is set to use `id` as the session identifier. If I add the `token` field as a workaround, BetterAuth then fails to generate a value for the `id` field, resulting in a `null value in column "id" of relation "sessions" violates not-null constraint` error. ## Steps to Reproduce 1. Use the following mapping in the BetterAuth config: ```ts session: { modelName: "sessions", fields: { id: "id", userId: "user_id", expiresAt: "expires_at", createdAt: "created_at", updatedAt: "updated_at", ipAddress: "ipAddress", userAgent: "userAgent" } }, advanced: { database: { generateId: true, // Also tried with generateId: false // Also tried with and without session: { idField: "id" } } } ``` 2. The `sessions` table schema is: ```sql CREATE TABLE public.sessions ( id character varying(255) NOT NULL, user_id integer NOT NULL, expires_at timestamp with time zone NOT NULL, created_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP, updated_at timestamp with time zone DEFAULT CURRENT_TIMESTAMP, "ipAddress" character varying(255), "userAgent" character varying(255) ); ``` 3. Call `auth.api.signInEmail({ body: { email, password }, ... })` in the login endpoint. ### Current vs. Expected behavior ## Expected Behavior - BetterAuth should use the `id` field as the session identifier and generate a value for it automatically (when `generateId: true`). - No reference to a `token` field in the `sessions` table should be made. ## Actual Behavior - If the `token` field does not exist in the `sessions` table, BetterAuth throws: `error: column "token" of relation "sessions" does not exist` - If I add the `token` field as a workaround, BetterAuth then throws: `error: null value in column "id" of relation "sessions" violates not-null constraint` - The `id` field is not being generated/populated. ### What version of Better Auth are you using? 1.2.12 ### Provide environment information ```bash ## Additional Info - Version: better-auth@1.2.12 - Node: v20.17.0 - Database: PostgreSQL (Neon) - Next.js: v15.2.4 - The mapping is correct and matches the docs and changelog for 1.2.10+. - I have tried cleaning node_modules, lockfile, and .next cache. - No other config files or overrides exist. ``` ### Which area(s) are affected? (Select all that apply) Backend, Client ### Auth config (if applicable) ```typescript session: { modelName: "sessions", fields: { id: "id", userId: "user_id", expiresAt: "expires_at", createdAt: "created_at", updatedAt: "updated_at", ipAddress: "ipAddress", userAgent: "userAgent" } }, advanced: { database: { generateId: true, // Also tried with generateId: false // Also tried with and without session: { idField: "id" } } } ``` ### Additional context ## Impact - Login and session creation are completely broken with the new mapping. - Downgrading to previous versions works only if the `token` field is present, but then logout/session management is broken. ## Request - Please clarify if there is a workaround, or fix the session creation logic to respect the mapping and generate the `id` as documented. Thank you!
GiteaMirror added the bug label 2026-03-13 08:41:56 -05:00
Author
Owner

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

Hi @ivarsmas! I'm Dosu and I’m helping the better-auth team.

This is a confirmed bug in BetterAuth 1.2.12: the session logic and adapters contain hardcoded references to the token field, so custom mapping to use id as the session identifier is not fully respected. Even with generateId: true, the id field is not generated or populated, and the codebase expects token to always exist in the sessions table. This is why removing token breaks session creation, and adding it causes id to be null and violate the NOT NULL constraint. The documentation and migration guides do not address this scenario, and there are no existing workarounds or config tweaks that resolve it—BetterAuth currently requires a token field in the session table for proper operation, regardless of mapping settings. A proper fix would require refactoring all session logic and adapters to respect the mapped identifier and generateId option throughout the codebase. For now, the only workaround is to keep the token field in your schema, but this may not resolve all issues with session management or logout. You can track this as a regression and monitor for updates or fixes in future releases.
Reference: session logic and mapping
Reference: session table model expectation

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 6, 2025): <!-- Greeting --> Hi @ivarsmas! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This is a confirmed bug in BetterAuth 1.2.12: the session logic and adapters contain hardcoded references to the token field, so custom mapping to use id as the session identifier is not fully respected. Even with generateId: true, the id field is not generated or populated, and the codebase expects token to always exist in the sessions table. This is why removing token breaks session creation, and adding it causes id to be null and violate the NOT NULL constraint. The documentation and migration guides do not address this scenario, and there are no existing workarounds or config tweaks that resolve it—BetterAuth currently requires a token field in the session table for proper operation, regardless of mapping settings. A proper fix would require refactoring all session logic and adapters to respect the mapped identifier and generateId option throughout the codebase. For now, the only workaround is to keep the token field in your schema, but this may not resolve all issues with session management or logout. You can track this as a regression and monitor for updates or fixes in future releases. [Reference: session logic and mapping](https://github.com/better-auth/better-auth/blob/2de1cd27f6177de7e18e57391eb1a0c5dc1cdda3/packages/better-auth/src/api/routes/session.ts) [Reference: session table model expectation](https://github.com/better-auth/better-auth/issues/2685) <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/01078523-a2a3-4219-ad6a-117dbd6ba302?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/01078523-a2a3-4219-ad6a-117dbd6ba302?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/01078523-a2a3-4219-ad6a-117dbd6ba302?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/01078523-a2a3-4219-ad6a-117dbd6ba302?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/01078523-a2a3-4219-ad6a-117dbd6ba302?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/01078523-a2a3-4219-ad6a-117dbd6ba302?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/01078523-a2a3-4219-ad6a-117dbd6ba302?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3281)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1469