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

databaseHooks.user.create.after causes foreign key constraint violation during social login with db transaction #2685

New Issue
Closed
opened 2026-03-13 10:13:02 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-03-13 10:13:02 -05:00
Owner
Copy Link

Originally created by @turisanapo on GitHub (Jan 11, 2026).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

1. Configure Better Auth with databaseHooks

import { betterAuth } from "better-auth";
import { prismaAdapter } from "better-auth/adapters/prisma";
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

export const auth = betterAuth({
  database: prismaAdapter(prisma, {
    provider: "postgresql",
    usePlural: true,
    transaction: true,
  }),
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    },
  },
  databaseHooks: {
    user: {
      create: {
        after: async (user) => {
          // Create an organization for the new user
          const org = await prisma.organizations.create({
            data: {
              id: crypto.randomUUID(),
              name: `${user.name}'s Org`,
              slug: `org-${user.id.slice(0, 8)}`,
            },
          });

          // This fails during social login
          await prisma.members.create({
            data: {
              id: crypto.randomUUID(),
              userId: user.id,
              organizationId: org.id,
              role: "owner",
            },
          });
        },
      },
    },
  },
});

2. Trigger the error

  1. Start the auth server
  2. Sign in with Google (or any social provider) as a new user
  3. Observe the error

Current vs. Expected behavior

Current behavior

Error:

PrismaClientKnownRequestError:
Invalid `prisma.members.create()` invocation:

Foreign key constraint violated on the constraint: `members_userId_fkey`

The after hook runs, but the Prisma client cannot see the user because it's still within Better Auth's uncommitted transaction. The hook's Prisma instance opens a new connection that cannot see uncommitted rows.

Expected behavior

The after hook should be able to create records that reference the newly created user via foreign key. Either:

  • The hook should run after the transaction is committed, OR
  • The hook should receive the transaction context to participate in the same transaction

What version of Better Auth are you using?

1.4.9

System info

{
  "system": {
    "platform": "darwin",
    "arch": "arm64",
    "version": "Darwin Kernel Version 25.1.0: Mon Oct 20 19:32:56 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T8132",
    "release": "25.1.0",
    "cpuCount": 10,
    "cpuModel": "Apple M4",
    "totalMemory": "16.00 GB",
    "freeMemory": "0.73 GB"
  },
  "node": {
    "version": "v24.9.0",
    "env": "development"
  },
  "packageManager": {
    "name": "bun",
    "version": "1.3.4"
  },
  "frameworks": null,
  "databases": [
    {
      "name": "pg",
      "version": "^8.16.3"
    },
    {
      "name": "@prisma/client",
      "version": "^7.1.0"
    }
  ],
  "betterAuth": {
    "version": "^1.4.5",
    "config": null
  }
}

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

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

The same databaseHooks.user.create.after hook works correctly when users sign up via email OTP, but fails with social login (OAuth).

Current workaround

Using hooks.after middleware instead of databaseHooks:

hooks: {
  after: createAuthMiddleware(async (ctx) => {
    if (ctx.path === "/callback/:id" || ctx.path.startsWith("/sign-up")) {
      const newSession = ctx.context.newSession;
      if (newSession) {
        // Transaction is committed here
        await createOrganization(newSession.user);
      }
    }
  }),
},

This works because hooks.after runs after the transaction commits, but it's less intuitive than using databaseHooks.

Originally created by @turisanapo on GitHub (Jan 11, 2026). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce ### 1. Configure Better Auth with databaseHooks ```typescript import { betterAuth } from "better-auth"; import { prismaAdapter } from "better-auth/adapters/prisma"; import { PrismaClient } from "@prisma/client"; const prisma = new PrismaClient(); export const auth = betterAuth({ database: prismaAdapter(prisma, { provider: "postgresql", usePlural: true, transaction: true, }), socialProviders: { google: { clientId: process.env.GOOGLE_CLIENT_ID!, clientSecret: process.env.GOOGLE_CLIENT_SECRET!, }, }, databaseHooks: { user: { create: { after: async (user) => { // Create an organization for the new user const org = await prisma.organizations.create({ data: { id: crypto.randomUUID(), name: `${user.name}'s Org`, slug: `org-${user.id.slice(0, 8)}`, }, }); // This fails during social login await prisma.members.create({ data: { id: crypto.randomUUID(), userId: user.id, organizationId: org.id, role: "owner", }, }); }, }, }, }, }); ``` ### 2. Trigger the error 1. Start the auth server 2. Sign in with Google (or any social provider) as a **new user** 3. Observe the error ### Current vs. Expected behavior ### Current behavior Error: ``` PrismaClientKnownRequestError: Invalid `prisma.members.create()` invocation: Foreign key constraint violated on the constraint: `members_userId_fkey` ``` The `after` hook runs, but the Prisma client cannot see the user because it's still within Better Auth's uncommitted transaction. The hook's Prisma instance opens a new connection that cannot see uncommitted rows. ### Expected behavior The `after` hook should be able to create records that reference the newly created user via foreign key. Either: - The hook should run after the transaction is committed, OR - The hook should receive the transaction context to participate in the same transaction ### What version of Better Auth are you using? 1.4.9 ### System info ```bash { "system": { "platform": "darwin", "arch": "arm64", "version": "Darwin Kernel Version 25.1.0: Mon Oct 20 19:32:56 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T8132", "release": "25.1.0", "cpuCount": 10, "cpuModel": "Apple M4", "totalMemory": "16.00 GB", "freeMemory": "0.73 GB" }, "node": { "version": "v24.9.0", "env": "development" }, "packageManager": { "name": "bun", "version": "1.3.4" }, "frameworks": null, "databases": [ { "name": "pg", "version": "^8.16.3" }, { "name": "@prisma/client", "version": "^7.1.0" } ], "betterAuth": { "version": "^1.4.5", "config": null } } ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context The same `databaseHooks.user.create.after` hook **works correctly** when users sign up via email OTP, but **fails** with social login (OAuth). ### Current workaround Using `hooks.after` middleware instead of `databaseHooks`: ```typescript hooks: { after: createAuthMiddleware(async (ctx) => { if (ctx.path === "/callback/:id" || ctx.path.startsWith("/sign-up")) { const newSession = ctx.context.newSession; if (newSession) { // Transaction is committed here await createOrganization(newSession.user); } } }), }, ``` This works because `hooks.after` runs after the transaction commits, but it's less intuitive than using `databaseHooks`.
GiteaMirror added the bug label 2026-03-13 10:13:02 -05:00
GiteaMirror commented 2026-03-13 10:13:03 -05:00
Author
Owner
Copy Link

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

The issue you are experiencing with the databaseHooks.user.create.after causing a foreign key constraint violation during social login (OAuth) is known and documented. This seems to occur because the after hook executes before the transaction has been committed, meaning the newly created user is not visible to the Prisma client executing in the after hook.

Troubleshooting Steps:

  1. Use hooks.after: As you mentioned, switching to hooks.after has worked as a workaround because it runs after the transaction is committed. This allows you to create the organization without hitting the foreign key constraint violation.
  2. Check for Updates: Ensure you are on the latest version of Better Auth. The problem might get resolved in future updates.

Here’s a reference to a similar issue that was logged:

  • There is an open issue where the databaseHooks.user.create.after does not consistently fire for Google OAuth signup as it does for email/password signup [1].

For the long-term solution, you can also consider tagging the Better Auth team (like @bekacru or @ping__) to keep track of when a fix might be implemented or to provide additional insights.

Is there anything else regarding Better Auth or your implementation that you would like to discuss?

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

Diagram • Discord • GitHub

Diagram Join Star

@better-auth-agent[bot] commented on GitHub (Jan 11, 2026): The issue you are experiencing with the `databaseHooks.user.create.after` causing a foreign key constraint violation during social login (OAuth) is known and documented. This seems to occur because the after hook executes before the transaction has been committed, meaning the newly created user is not visible to the Prisma client executing in the after hook. ### Troubleshooting Steps: 1. **Use `hooks.after`:** As you mentioned, switching to `hooks.after` has worked as a workaround because it runs after the transaction is committed. This allows you to create the organization without hitting the foreign key constraint violation. 2. **Check for Updates:** Ensure you are on the latest version of Better Auth. The problem might get resolved in future updates. Here’s a reference to a similar issue that was logged: - There is an open issue where the `databaseHooks.user.create.after` does not consistently fire for Google OAuth signup as it does for email/password signup [[1]](https://github.com/better-auth/better-auth/issues/4745). For the long-term solution, you can also consider tagging the Better Auth team (like @bekacru or @ping__) to keep track of when a fix might be implemented or to provide additional insights. Is there anything else regarding Better Auth or your implementation that you would like to discuss? _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/skyvern_ultra_detailed_interactive.html) • [Discord](https://discord.gg/fG2XXEuQX3) • [GitHub](https://github.com/Skyvern-AI/Skyvern) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/skyvern_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/fG2XXEuQX3) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/Skyvern-AI/Skyvern)
GiteaMirror commented 2026-03-13 10:13:04 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jan 11, 2026):

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

This is expected behavior in Better Auth since v1.3.10: the databaseHooks.user.create.after hook runs before the user creation transaction is committed, so any new Prisma client (or database connection) inside the hook cannot see the uncommitted user row. This causes foreign key constraint violations when you try to create related records referencing the new user, especially with social login flows that always run inside a transaction. The same issue can happen with email OTP if the transaction is enabled, but differences in timing or flow may make it less apparent in some cases [source]source.

There is currently no way to run the after hook post-commit or to pass the transaction context to the hook so it can participate in the same transaction. The recommended workaround is to defer creation of related records until after the transaction commits—using hooks.after middleware, a setTimeout in the hook, or triggering the logic on first dashboard access. All these approaches ensure the user is fully committed and visible to other database connections [source]source].

If you need to create related records immediately after user creation, structuring your logic to run post-commit (outside databaseHooks) is the safest approach. Doing persistence operations in databaseHooks.user.create.after that depend on committed state is considered an anti-pattern in Better Auth [source].

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 11, 2026): <!-- Greeting --> Hi @turisanapo! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> This is expected behavior in Better Auth since v1.3.10: the `databaseHooks.user.create.after` hook runs before the user creation transaction is committed, so any new Prisma client (or database connection) inside the hook cannot see the uncommitted user row. This causes foreign key constraint violations when you try to create related records referencing the new user, especially with social login flows that always run inside a transaction. The same issue can happen with email OTP if the transaction is enabled, but differences in timing or flow may make it less apparent in some cases [[source](https://github.com/better-auth/better-auth/issues/4718)][source](https://github.com/better-auth/better-auth/issues/4745). There is currently no way to run the `after` hook post-commit or to pass the transaction context to the hook so it can participate in the same transaction. The recommended workaround is to defer creation of related records until after the transaction commits—using `hooks.after` middleware, a `setTimeout` in the hook, or triggering the logic on first dashboard access. All these approaches ensure the user is fully committed and visible to other database connections [[source](https://github.com/better-auth/better-auth/issues/6791)][source](https://github.com/better-auth/better-auth/issues/4745)]. If you need to create related records immediately after user creation, structuring your logic to run post-commit (outside `databaseHooks`) is the safest approach. Doing persistence operations in `databaseHooks.user.create.after` that depend on committed state is considered an anti-pattern in Better Auth [[source](https://github.com/better-auth/better-auth/issues/1060)]. <!-- 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/72849d97-9128-46ea-8ac9-316f13b57b1c?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/72849d97-9128-46ea-8ac9-316f13b57b1c?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/72849d97-9128-46ea-8ac9-316f13b57b1c?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/72849d97-9128-46ea-8ac9-316f13b57b1c?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/72849d97-9128-46ea-8ac9-316f13b57b1c?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/72849d97-9128-46ea-8ac9-316f13b57b1c?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/72849d97-9128-46ea-8ac9-316f13b57b1c?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20is%20expected%20behavior%20in%20Better%20Auth%20since%20v1.3.10%3A%20the%20%60databaseHooks.user.create.after%60%20hook%20runs%20before%20the%20user%20creation%20transaction%20is%20committed%2C%20so%20any%20new%20Prisma%20client%20%28or%20database%20connection%29%20inside%20the%20hook%20cannot%20see%20the%20uncommitted%20user%20row.%20This%20causes%20foreign%20key%20constraint%20violations%20when%20you%20try%20to%20create%20related%20records%20referencing%20the%20new%20user%2C%20especially%20with%20social%20login%20flows%20that%20always%20run%20inside%20a%20transaction.%20The%20same%20issue%20can%20happen%20with%20email%20OTP%20if%20the%20transaction%20is%20enabled%2C%20but%20differences%20in%20timing%20or%20flow%20may%20make%20it%20less%20apparent%20in%20some%20cases%20%5B%5Bsource%5D%28https%3A//github.com/better-auth/better-auth/issues/4718%29%5D%5Bsource%5D%28https%3A//github.com/better-auth/better-auth/issues/4745%29.%0A%0AThere%20is%20currently%20no%20way%20to%20run%20the%20%60after%60%20hook%20post-commit%20or%20to%20pass%20the%20transaction%20context%20to%20the%20hook%20so%20it%20can%20participate%20in%20the%20same%20transaction.%20The%20recommended%20workaround%20is%20to%20defer%20creation%20of%20related%20records%20until%20after%20the%20transaction%20commits%E2%80%94using%20%60hooks.after%60%20middleware%2C%20a%20%60setTimeout%60%20in%20the%20hook%2C%20or%20triggering%20the%20logic%20on%20first%20dashboard%20access.%20All%20these%20approaches%20ensure%20the%20user%20is%20fully%20committed%20and%20visible%20to%20other%20database%20connections%20%5B%5Bsource%5D%28https%3A//github.com/better-auth/better-auth/issues/6791%29%5D%5Bsource%5D%28https%3A//github.com/better-auth/better-auth/issues/4745%29%5D.%0A%0AIf%20you%20need%20to%20create%20related%20records%20immediately%20after%20user%20creation%2C%20structuring%20your%20logic%20to%20run%20post-commit%20%28outside%20%60databaseHooks%60%29%20is%20the%20safest%20approach.%20Doing%20persistence%20operations%20in%20%60databaseHooks.user.create.after%60%20that%20depend%20on%20committed%20state%20is%20considered%20an%20anti-pattern%20in%20Better%20Auth%20%5B%5Bsource%5D%28https%3A//github.com/better-auth/better-auth/issues/1060%29%5D.)&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/7260)
GiteaMirror commented 2026-03-13 10:13:04 -05:00
Author
Owner
Copy Link

@bytaesu commented on GitHub (Jan 11, 2026):

Hi @turisanapo, I'm checking this!

@bytaesu commented on GitHub (Jan 11, 2026): Hi @turisanapo, I'm checking this!
GiteaMirror commented 2026-03-13 10:13:05 -05:00
Author
Owner
Copy Link

@waliilaw commented on GitHub (Jan 13, 2026):

I’m planning to open a PR to address this by adding a databaseHooks.user.create.afterCommit hook that runs post-transaction, so FK-dependent inserts work safely
I’ll keep it fully backward-compatible , will open a draft PR soon

@waliilaw commented on GitHub (Jan 13, 2026): I’m planning to open a PR to address this by adding a databaseHooks.user.create.afterCommit hook that runs post-transaction, so FK-dependent inserts work safely I’ll keep it fully backward-compatible , will open a draft PR soon
GiteaMirror commented 2026-03-13 10:13:05 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Jan 13, 2026):

My comment: https://github.com/better-auth/better-auth/pull/7330#pullrequestreview-3658169756

We should delay all of the DB hooks calls after the trx

@claude, can you open a PR to implement my suggestion and fix this?

@himself65 commented on GitHub (Jan 13, 2026): My comment: https://github.com/better-auth/better-auth/pull/7330#pullrequestreview-3658169756 We should delay all of the DB hooks calls after the trx @claude, can you open a PR to implement my suggestion and fix this?
GiteaMirror commented 2026-03-13 10:13:05 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 13, 2026):

Claude finished @himself65's task in 5m 5s —— View job • claude/issue-7260-20260113-2226 • Create PR ➔

Implementation Complete ✓

I've successfully implemented the fix to delay all database hooks execution until after transaction commits, addressing issue #7260.

Changes Made

  1. packages/core/src/context/transaction.ts:

    • Added HookContext type with adapter and pendingHooks array
    • Modified runWithTransaction to collect and execute hooks after transaction commits
    • Added queueAfterTransactionHook() function to queue hooks or execute immediately if not in a transaction

  2. packages/better-auth/src/db/with-hooks.ts:

    • Updated all after hooks (create, update, delete) to use queueAfterTransactionHook()
    • Hooks now queue during transaction and execute after commit

  3. packages/core/src/context/index.ts:

    • Exported queueAfterTransactionHook for external use

How It Works

  • When inside a transaction, after hooks are queued in the AsyncLocalStorage context
  • After transaction commits successfully, all queued hooks execute in order
  • If transaction fails/rolls back, queued hooks never execute
  • When NOT in a transaction, hooks execute immediately (backward compatible)

Why This Fixes the Issue

The original issue occurred because:

  1. createOAuthUser wraps user/account creation in a transaction
  2. After hooks executed INSIDE the transaction, before commit
  3. External Prisma clients couldn't see uncommitted rows
  4. Creating related records via FK caused constraint violations

Now:

  • Hooks execute AFTER transaction commits
  • External Prisma clients can see the committed user row
  • Related records can be created successfully via foreign keys
  • Maintains transactional integrity - hooks only run on successful commits

Branch & PR

Branch: claude/issue-7260-20260113-2226

| Branch

@github-actions[bot] commented on GitHub (Jan 13, 2026): **Claude finished @himself65's task in 5m 5s** —— [View job](https://github.com/better-auth/better-auth/actions/runs/20974839901) • [`claude/issue-7260-20260113-2226`](https://github.com/better-auth/better-auth/tree/claude/issue-7260-20260113-2226) • [Create PR ➔](https://github.com/better-auth/better-auth/compare/canary...claude/issue-7260-20260113-2226?quick_pull=1&title=fix%3A%20delay%20database%20hooks%20execution%20until%20after%20transaction%20commits&body=%23%23%23%20Summary%0A%0AThis%20PR%20fixes%20issue%20%237260%20where%20%60databaseHooks.user.create.after%60%20causes%20foreign%20key%20constraint%20violations%20during%20social%20login%20with%20database%20transactions%20enabled.%0A%0A%23%23%23%20Problem%0A%0AThe%20issue%20occurred%20because%20after%20hooks%20executed%20INSIDE%20the%20transaction%20before%20commit%2C%20so%20external%20Prisma%20clients%20couldn%27t%20see%20uncommitted%20rows.%20This%20caused%20FK%20constraint%20violations%20when%20hooks%20tried%20to%20create%20related%20records%20that%20reference%20the%20new%20user.%0A%0A%23%23%23%20Solution%0A%0A-%20Modified%20%60runWithTransaction%60%20to%20queue%20after%20hooks%20and%20execute%20them%20post-commit%0A-%20Added%20%60queueAfterTransactionHook%60%20function%20to%20queue%20hooks%20in%20transaction%20context%0A-%20Updated%20all%20after%20hooks%20%28create%2C%20update%2C%20delete%29%20to%20use%20the%20queue%20mechanism%0A-%20Hooks%20execute%20immediately%20if%20not%20in%20a%20transaction%20%28backward%20compatible%29%0A-%20If%20transaction%20fails%2C%20queued%20hooks%20never%20execute%0A%0A%23%23%23%20Benefits%0A%0A-%20External%20DB%20clients%20can%20now%20see%20committed%20rows%20in%20after%20hooks%0A-%20Maintains%20transactional%20integrity%20-%20hooks%20only%20run%20on%20successful%20commits%0A-%20Prevents%20FK%20constraint%20violations%0A-%20Fully%20backward%20compatible%0A%0A%23%23%23%20Testing%0A%0AExisting%20tests%20should%20continue%20to%20pass.%20The%20change%20is%20backward%20compatible%20because%3A%0A-%20Hooks%20still%20execute%20after%20DB%20writes%20complete%0A-%20Hooks%20that%20use%20the%20same%20adapter%20context%20will%20work%20as%20before%0A-%20Hooks%20that%20use%20external%20clients%20will%20now%20work%20correctly%0A%0AFixes%20%237260%0A%0A---%0A%0AGenerated%20with%20%5BClaude%20Code%5D%28https%3A//claude.ai/code%29) --- ### Implementation Complete ✓ I've successfully implemented the fix to delay all database hooks execution until after transaction commits, addressing issue #7260. ### Changes Made 1. **`packages/core/src/context/transaction.ts`**: - Added `HookContext` type with `adapter` and `pendingHooks` array - Modified `runWithTransaction` to collect and execute hooks after transaction commits - Added `queueAfterTransactionHook()` function to queue hooks or execute immediately if not in a transaction 2. **`packages/better-auth/src/db/with-hooks.ts`**: - Updated all `after` hooks (create, update, delete) to use `queueAfterTransactionHook()` - Hooks now queue during transaction and execute after commit 3. **`packages/core/src/context/index.ts`**: - Exported `queueAfterTransactionHook` for external use ### How It Works - When inside a transaction, after hooks are queued in the AsyncLocalStorage context - After transaction commits successfully, all queued hooks execute in order - If transaction fails/rolls back, queued hooks never execute - When NOT in a transaction, hooks execute immediately (backward compatible) ### Why This Fixes the Issue The original issue occurred because: 1. `createOAuthUser` wraps user/account creation in a transaction 2. After hooks executed INSIDE the transaction, before commit 3. External Prisma clients couldn't see uncommitted rows 4. Creating related records via FK caused constraint violations Now: - Hooks execute AFTER transaction commits - External Prisma clients can see the committed user row - Related records can be created successfully via foreign keys - Maintains transactional integrity - hooks only run on successful commits ### Branch & PR Branch: [`claude/issue-7260-20260113-2226`](https://github.com/better-auth/better-auth/tree/claude/issue-7260-20260113-2226) --- | [Branch](https://github.com/better-auth/better-auth/tree/claude/issue-7260-20260113-2226)
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
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#2685
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?