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

[GH-ISSUE #6469] (Prisma v7) Users not getting updated when using authClient.updateUser() or authClient.changeEmail() #27848

New Issue
Open
opened 2026-04-17 19:04:53 -05:00 by GiteaMirror · 22 comments
GiteaMirror commented 2026-04-17 19:04:53 -05:00
Owner
Copy Link

Originally created by @alexwork1611 on GitHub (Dec 2, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/6469

Originally assigned to: @ping-maxwell on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

After upgrading to Prisma v7, whenever I try to use authClient.updateUser() or authClient.changeEmail(), I get a success message from the backend, saying that the updates were successful. But when I look at the database, the user was not updated.

Current vs. Expected behavior

No update vs. update

What version of Better Auth are you using?

1.4.4

System info

{
  "system": {
    "platform": "win32",
    "arch": "x64",
    "version": "Windows 11 Pro",
    "release": "10.0.26200",
    "cpuCount": 16,
    "cpuModel": "AMD Ryzen 9 8945H w/ Radeon 780M Graphics",
    "totalMemory": "15.26 GB",
    "freeMemory": "1.22 GB"
  },
  "node": {
    "version": "v24.11.0",
    "env": "development"
  },
  "packageManager": {
    "name": "pnpm",
    "version": "10.19.0"
  },
  "frameworks": [
    {
      "name": "react",
      "version": "^19.2.0"
    }
  ],
  "databases": [
    {
      "name": "@prisma/client",
      "version": "^7.0.1"
    }
  ],
  "betterAuth": {
    "version": "^1.4.4",
    "config": {
      "baseURL": "http://localhost:3000",
      "trustedOrigins": [
      ],
      "emailAndPassword": {
        "enabled": true,
        "requireEmailVerification": false,
        "autoSignIn": true
      },
      "emailVerification": {},
      "databaseHooks": {
        "user": {
          "update": {}
        }
      },
      "socialProviders": {
        "google": {
          "clientId": "[REDACTED]",
          "clientSecret": "[REDACTED]"
        },
        "apple": {
          "clientId": "[REDACTED]",
          "clientSecret": "[REDACTED]"
        },
        "facebook": {
          "clientId": "[REDACTED]",
          "clientSecret": "[REDACTED]"
        }
      },
      "plugins": [
        {
          "name": "passkey",
          "config": {
            "id": "passkey",
            "endpoints": {},
            "schema": {
              "passkey": {
                "fields": {
                  "name": {
                    "type": "string",
                    "required": false
                  },
                  "publicKey": {
                    "type": "string",
                    "required": true
                  },
                  "userId": {
                    "type": "string",
                    "references": {
                      "model": "user",
                      "field": "id"
                    },
                    "required": true,
                    "index": true
                  },
                  "credentialID": {
                    "type": "string",
                    "required": true,
                    "index": true
                  },
                  "counter": {
                    "type": "number",
                    "required": true
                  },
                  "deviceType": {
                    "type": "string",
                    "required": true
                  },
                  "backedUp": {
                    "type": "boolean",
                    "required": true
                  },
                  "transports": {
                    "type": "string",
                    "required": false
                  },
                  "createdAt": {
                    "type": "date",
                    "required": false
                  },
                  "aaguid": {
                    "type": "string",
                    "required": false
                  }
                }
              }
            },
            "$ERROR_CODES": {
              "CHALLENGE_NOT_FOUND": "Challenge not found",
              "YOU_ARE_NOT_ALLOWED_TO_REGISTER_THIS_PASSKEY": "You are not allowed to register this passkey",
              "FAILED_TO_VERIFY_REGISTRATION": "Failed to verify registration",
              "PASSKEY_NOT_FOUND": "Passkey not found",
              "AUTHENTICATION_FAILED": "Authentication failed",
              "UNABLE_TO_CREATE_SESSION": "Unable to create session",
              "FAILED_TO_UPDATE_PASSKEY": "Failed to update passkey"
            }
          }
        },
        {
          "name": "two-factor",
          "config": {
            "id": "two-factor",
            "endpoints": {},
            "hooks": {
              "after": [
                {}
              ]
            },
            "schema": {
              "user": {
                "fields": {
                  "twoFactorEnabled": {
                    "type": "boolean",
                    "required": false,
                    "defaultValue": false,
                    "input": false
                  }
                }
              },
              "twoFactor": {
                "fields": {
                  "secret": {
                    "type": "string",
                    "required": true,
                    "returned": false,
                    "index": true
                  },
                  "backupCodes": {
                    "type": "string",
                    "required": true,
                    "returned": false
                  },
                  "userId": {
                    "type": "string",
                    "required": true,
                    "returned": false,
                    "references": {
                      "model": "user",
                      "field": "id"
                    },
                    "index": true
                  }
                }
              }
            },
            "rateLimit": [
              {
                "window": 10,
                "max": 3
              }
            ],
            "$ERROR_CODES": {
              "OTP_NOT_ENABLED": "OTP not enabled",
              "OTP_HAS_EXPIRED": "OTP has expired",
              "TOTP_NOT_ENABLED": "TOTP not enabled",
              "TWO_FACTOR_NOT_ENABLED": "Two factor isn't enabled",
              "BACKUP_CODES_NOT_ENABLED": "Backup codes aren't enabled",
              "INVALID_BACKUP_CODE": "Invalid backup code",
              "INVALID_CODE": "Invalid code",
              "TOO_MANY_ATTEMPTS_REQUEST_NEW_CODE": "Too many attempts. Please request a new code.",
              "INVALID_TWO_FACTOR_COOKIE": "Invalid two factor cookie"
            }
          }
        },
        {
          "name": "magic-link",
          "config": {
            "id": "magic-link",
            "endpoints": {},
            "rateLimit": [
              {
                "window": 60,
                "max": 5
              }
            ]
          }
        }
      ],
      "user": {
        "changeEmail": {
          "enabled": true
        },
        "additionalFields": {
        }
      }
    }
  }
}

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

Backend

Auth config (if applicable)

import { envValidationSchema } from '@/validation/env-validation-schema'
import { passkey } from '@better-auth/passkey'
import { betterAuth } from 'better-auth'
import { prismaAdapter } from 'better-auth/adapters/prisma'
import { magicLink, twoFactor } from 'better-auth/plugins'
import { prisma } from '~prisma/prisma'

export const auth = betterAuth({
	emailAndPassword: {
		enabled: true,
		requireEmailVerification: false,
		autoSignIn: true,
	},
	emailVerification: {
		sendVerificationEmail: async ({ user, url }) => {
			await prisma.user.sendVerificationEmail(user, url)
		},
	},
	plugins: [
		passkey(),
		twoFactor(),
		magicLink({
			sendMagicLink: async (data) => {
				await prisma.user.sendMagicLink(data)
			},
		}),
	],
	database: prismaAdapter(prisma, {
		provider: 'postgresql',
	}),
})

Additional context

No response

Originally created by @alexwork1611 on GitHub (Dec 2, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/6469 Originally assigned to: @ping-maxwell on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce After upgrading to Prisma v7, whenever I try to use `authClient.updateUser()` or `authClient.changeEmail()`, I get a success message from the backend, saying that the updates were successful. But when I look at the database, the user was not updated. ### Current vs. Expected behavior No update vs. update ### What version of Better Auth are you using? 1.4.4 ### System info ```bash { "system": { "platform": "win32", "arch": "x64", "version": "Windows 11 Pro", "release": "10.0.26200", "cpuCount": 16, "cpuModel": "AMD Ryzen 9 8945H w/ Radeon 780M Graphics", "totalMemory": "15.26 GB", "freeMemory": "1.22 GB" }, "node": { "version": "v24.11.0", "env": "development" }, "packageManager": { "name": "pnpm", "version": "10.19.0" }, "frameworks": [ { "name": "react", "version": "^19.2.0" } ], "databases": [ { "name": "@prisma/client", "version": "^7.0.1" } ], "betterAuth": { "version": "^1.4.4", "config": { "baseURL": "http://localhost:3000", "trustedOrigins": [ ], "emailAndPassword": { "enabled": true, "requireEmailVerification": false, "autoSignIn": true }, "emailVerification": {}, "databaseHooks": { "user": { "update": {} } }, "socialProviders": { "google": { "clientId": "[REDACTED]", "clientSecret": "[REDACTED]" }, "apple": { "clientId": "[REDACTED]", "clientSecret": "[REDACTED]" }, "facebook": { "clientId": "[REDACTED]", "clientSecret": "[REDACTED]" } }, "plugins": [ { "name": "passkey", "config": { "id": "passkey", "endpoints": {}, "schema": { "passkey": { "fields": { "name": { "type": "string", "required": false }, "publicKey": { "type": "string", "required": true }, "userId": { "type": "string", "references": { "model": "user", "field": "id" }, "required": true, "index": true }, "credentialID": { "type": "string", "required": true, "index": true }, "counter": { "type": "number", "required": true }, "deviceType": { "type": "string", "required": true }, "backedUp": { "type": "boolean", "required": true }, "transports": { "type": "string", "required": false }, "createdAt": { "type": "date", "required": false }, "aaguid": { "type": "string", "required": false } } } }, "$ERROR_CODES": { "CHALLENGE_NOT_FOUND": "Challenge not found", "YOU_ARE_NOT_ALLOWED_TO_REGISTER_THIS_PASSKEY": "You are not allowed to register this passkey", "FAILED_TO_VERIFY_REGISTRATION": "Failed to verify registration", "PASSKEY_NOT_FOUND": "Passkey not found", "AUTHENTICATION_FAILED": "Authentication failed", "UNABLE_TO_CREATE_SESSION": "Unable to create session", "FAILED_TO_UPDATE_PASSKEY": "Failed to update passkey" } } }, { "name": "two-factor", "config": { "id": "two-factor", "endpoints": {}, "hooks": { "after": [ {} ] }, "schema": { "user": { "fields": { "twoFactorEnabled": { "type": "boolean", "required": false, "defaultValue": false, "input": false } } }, "twoFactor": { "fields": { "secret": { "type": "string", "required": true, "returned": false, "index": true }, "backupCodes": { "type": "string", "required": true, "returned": false }, "userId": { "type": "string", "required": true, "returned": false, "references": { "model": "user", "field": "id" }, "index": true } } } }, "rateLimit": [ { "window": 10, "max": 3 } ], "$ERROR_CODES": { "OTP_NOT_ENABLED": "OTP not enabled", "OTP_HAS_EXPIRED": "OTP has expired", "TOTP_NOT_ENABLED": "TOTP not enabled", "TWO_FACTOR_NOT_ENABLED": "Two factor isn't enabled", "BACKUP_CODES_NOT_ENABLED": "Backup codes aren't enabled", "INVALID_BACKUP_CODE": "Invalid backup code", "INVALID_CODE": "Invalid code", "TOO_MANY_ATTEMPTS_REQUEST_NEW_CODE": "Too many attempts. Please request a new code.", "INVALID_TWO_FACTOR_COOKIE": "Invalid two factor cookie" } } }, { "name": "magic-link", "config": { "id": "magic-link", "endpoints": {}, "rateLimit": [ { "window": 60, "max": 5 } ] } } ], "user": { "changeEmail": { "enabled": true }, "additionalFields": { } } } } } ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { envValidationSchema } from '@/validation/env-validation-schema' import { passkey } from '@better-auth/passkey' import { betterAuth } from 'better-auth' import { prismaAdapter } from 'better-auth/adapters/prisma' import { magicLink, twoFactor } from 'better-auth/plugins' import { prisma } from '~prisma/prisma' export const auth = betterAuth({ emailAndPassword: { enabled: true, requireEmailVerification: false, autoSignIn: true, }, emailVerification: { sendVerificationEmail: async ({ user, url }) => { await prisma.user.sendVerificationEmail(user, url) }, }, plugins: [ passkey(), twoFactor(), magicLink({ sendMagicLink: async (data) => { await prisma.user.sendMagicLink(data) }, }), ], database: prismaAdapter(prisma, { provider: 'postgresql', }), }) ``` ### Additional context _No response_
GiteaMirror added the databasebug labels 2026-04-17 19:04:53 -05:00
GiteaMirror commented 2026-04-17 19:04:55 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Dec 2, 2025):

Hey there, thanks for reporting this issue. It appears that after migrating to Prisma v7, the updateUser and changeEmail calls in the authClient return a success response even though the database isn’t being updated. Here are a few troubleshooting steps to follow:

• Confirm that your Prisma adapter and schema are fully up-to-date with Prisma v7 changes. Sometimes breaking changes may require adjustments in how the adapter maps updates to your database.

• Verify that any database hooks or middleware (for example, in your user.update configuration) aren’t interfering with the update process. It can help to temporarily disable hooks and log the raw inputs and outputs to ensure that updates are correctly passing through.

• Double-check that your Prisma migration ran successfully and that the schema in your database reflects the expected fields. Prisma v7 may have introduced subtle changes that affect how fields are updated.

• Enable additional logging or debug mode in your Prisma adapter to capture more details about the update operations. This might reveal discrepancies between the update response and what’s actually executed.

If these suggestions don’t resolve the issue, it could be a bug or compatibility gap with Prisma v7. In that case, I’d recommend reaching out to the team by tagging @bekacru and @ping__ for further assistance.

tag @better-auth-agent if you would like an answer from the Agent

How do these steps sound to you? Are there any additional log details or patterns you’ve noticed that might help narrow down the issue?

If you need more help, tag @Skyvern in a comment so I can respond.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3601424202 --> @better-auth-agent[bot] commented on GitHub (Dec 2, 2025): Hey there, thanks for reporting this issue. It appears that after migrating to Prisma v7, the updateUser and changeEmail calls in the authClient return a success response even though the database isn’t being updated. Here are a few troubleshooting steps to follow: • Confirm that your Prisma adapter and schema are fully up-to-date with Prisma v7 changes. Sometimes breaking changes may require adjustments in how the adapter maps updates to your database. • Verify that any database hooks or middleware (for example, in your user.update configuration) aren’t interfering with the update process. It can help to temporarily disable hooks and log the raw inputs and outputs to ensure that updates are correctly passing through. • Double-check that your Prisma migration ran successfully and that the schema in your database reflects the expected fields. Prisma v7 may have introduced subtle changes that affect how fields are updated. • Enable additional logging or debug mode in your Prisma adapter to capture more details about the update operations. This might reveal discrepancies between the update response and what’s actually executed. If these suggestions don’t resolve the issue, it could be a bug or compatibility gap with Prisma v7. In that case, I’d recommend reaching out to the team by tagging @bekacru and @ping__ for further assistance. tag @better-auth-agent if you would like an answer from the Agent How do these steps sound to you? Are there any additional log details or patterns you’ve noticed that might help narrow down the issue? _If you need more help, tag @Skyvern 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-04-17 19:04:56 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Dec 2, 2025):

This is a known issue when using Better Auth v1.4.4 with Prisma v7. Prisma v7 introduced breaking changes that the Better Auth CLI and schema generator do not yet fully support, which can cause update operations (like authClient.updateUser() and authClient.changeEmail()) to silently fail—returning success but not actually updating the database. This typically happens if the Prisma schema, config, or import paths are not manually updated after each CLI run, or if unique constraints and model/field names do not match exactly between your schema and Better Auth config details details.

To work around this until full Prisma v7 support lands:

  1. After running the Better Auth CLI, manually update your Prisma schema:
    • Move connection settings (url, directUrl, shadowDatabaseUrl) from schema.prisma to a new prisma.config.ts file.
    • Change the generator provider from "prisma-client-js" to "prisma-client".
    • Update your import paths to use the generated client (e.g., import { PrismaClient } from "@/generated/prisma/client").
    • Explicitly use the correct Prisma adapter package (like @prisma/adapter-pg for PostgreSQL) reference reference.
  2. Double-check that all model and field names in your Better Auth config exactly match your Prisma schema, and that all fields used in where clauses (especially id) are marked as @unique in your schema reference.
  3. Enable debug logging in your adapter to catch any silent errors.
  4. Repeat these manual schema/config updates after every CLI run, as the CLI will overwrite them.

There is no automated fix yet, but maintainers are aware and working on full Prisma v7 support. Until then, these manual steps are required to avoid silent failures in update operations reference reference.

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

<!-- gh-comment-id:3601433932 --> @dosubot[bot] commented on GitHub (Dec 2, 2025): <!-- Answer --> This is a known issue when using Better Auth v1.4.4 with Prisma v7. Prisma v7 introduced breaking changes that the Better Auth CLI and schema generator do not yet fully support, which can cause update operations (like `authClient.updateUser()` and `authClient.changeEmail()`) to silently fail—returning success but not actually updating the database. This typically happens if the Prisma schema, config, or import paths are not manually updated after each CLI run, or if unique constraints and model/field names do not match exactly between your schema and Better Auth config [details](https://github.com/better-auth/better-auth/issues/6354) [details](https://github.com/better-auth/better-auth/issues/6277). **To work around this until full Prisma v7 support lands:** 1. After running the Better Auth CLI, manually update your Prisma schema: - Move connection settings (`url`, `directUrl`, `shadowDatabaseUrl`) from `schema.prisma` to a new `prisma.config.ts` file. - Change the generator provider from `"prisma-client-js"` to `"prisma-client"`. - Update your import paths to use the generated client (e.g., `import { PrismaClient } from "@/generated/prisma/client"`). - Explicitly use the correct Prisma adapter package (like `@prisma/adapter-pg` for PostgreSQL) [reference](https://github.com/better-auth/better-auth/issues/6277) [reference](https://github.com/better-auth/better-auth/issues/6112). 2. Double-check that all model and field names in your Better Auth config exactly match your Prisma schema, and that all fields used in `where` clauses (especially `id`) are marked as `@unique` in your schema [reference](https://github.com/better-auth/better-auth/issues/2114). 3. Enable debug logging in your adapter to catch any silent errors. 4. Repeat these manual schema/config updates after every CLI run, as the CLI will overwrite them. There is no automated fix yet, but maintainers are aware and working on full Prisma v7 support. Until then, these manual steps are required to avoid silent failures in update operations [reference](https://github.com/better-auth/better-auth/issues/6354) [reference](https://github.com/better-auth/better-auth/issues/6277). <!-- 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/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?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%20a%20known%20issue%20when%20using%20Better%20Auth%20v1.4.4%20with%20Prisma%20v7.%20Prisma%20v7%20introduced%20breaking%20changes%20that%20the%20Better%20Auth%20CLI%20and%20schema%20generator%20do%20not%20yet%20fully%20support%2C%20which%20can%20cause%20update%20operations%20%28like%20%60authClient.updateUser%28%29%60%20and%20%60authClient.changeEmail%28%29%60%29%20to%20silently%20fail%E2%80%94returning%20success%20but%20not%20actually%20updating%20the%20database.%20This%20typically%20happens%20if%20the%20Prisma%20schema%2C%20config%2C%20or%20import%20paths%20are%20not%20manually%20updated%20after%20each%20CLI%20run%2C%20or%20if%20unique%20constraints%20and%20model/field%20names%20do%20not%20match%20exactly%20between%20your%20schema%20and%20Better%20Auth%20config%C2%A0%5Bdetails%5D%28https%3A//github.com/better-auth/better-auth/issues/6354%29%C2%A0%5Bdetails%5D%28https%3A//github.com/better-auth/better-auth/issues/6277%29.%0A%0A%2A%2ATo%20work%20around%20this%20until%20full%20Prisma%20v7%20support%20lands%3A%2A%2A%0A%0A1.%20After%20running%20the%20Better%20Auth%20CLI%2C%20manually%20update%20your%20Prisma%20schema%3A%0A%20%20%20-%20Move%20connection%20settings%20%28%60url%60%2C%20%60directUrl%60%2C%20%60shadowDatabaseUrl%60%29%20from%20%60schema.prisma%60%20to%20a%20new%20%60prisma.config.ts%60%20file.%0A%20%20%20-%20Change%20the%20generator%20provider%20from%20%60%22prisma-client-js%22%60%20to%20%60%22prisma-client%22%60.%0A%20%20%20-%20Update%20your%20import%20paths%20to%20use%20the%20generated%20client%20%28e.g.%2C%20%60import%20%7B%20PrismaClient%20%7D%20from%20%22%40/generated/prisma/client%22%60%29.%0A%20%20%20-%20Explicitly%20use%20the%20correct%20Prisma%20adapter%20package%20%28like%20%60%40prisma/adapter-pg%60%20for%20PostgreSQL%29%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6277%29%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6112%29.%0A2.%20Double-check%20that%20all%20model%20and%20field%20names%20in%20your%20Better%20Auth%20config%20exactly%20match%20your%20Prisma%20schema%2C%20and%20that%20all%20fields%20used%20in%20%60where%60%20clauses%20%28especially%20%60id%60%29%20are%20marked%20as%20%60%40unique%60%20in%20your%20schema%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/2114%29.%0A3.%20Enable%20debug%20logging%20in%20your%20adapter%20to%20catch%20any%20silent%20errors.%0A4.%20Repeat%20these%20manual%20schema/config%20updates%20after%20every%20CLI%20run%2C%20as%20the%20CLI%20will%20overwrite%20them.%0A%0AThere%20is%20no%20automated%20fix%20yet%2C%20but%20maintainers%20are%20aware%20and%20working%20on%20full%20Prisma%20v7%20support.%20Until%20then%2C%20these%20manual%20steps%20are%20required%20to%20avoid%20silent%20failures%20in%20update%20operations%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6354%29%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6277%29.)&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/6469)
GiteaMirror commented 2026-04-17 19:04:57 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Dec 2, 2025):

/cc @ping-maxwell

<!-- gh-comment-id:3604059467 --> @himself65 commented on GitHub (Dec 2, 2025): /cc @ping-maxwell
GiteaMirror commented 2026-04-17 19:04:58 -05:00
Author
Owner
Copy Link

@DevDuki commented on GitHub (Dec 6, 2025):

I'm experiencing the same issue 🙈 Is there a workaround for now?

<!-- gh-comment-id:3620619738 --> @DevDuki commented on GitHub (Dec 6, 2025): I'm experiencing the same issue 🙈 Is there a workaround for now?
GiteaMirror commented 2026-04-17 19:04:59 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Dec 8, 2025):

Looking into this

<!-- gh-comment-id:3623901396 --> @ping-maxwell commented on GitHub (Dec 8, 2025): Looking into this
GiteaMirror commented 2026-04-17 19:04:59 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Dec 8, 2025):

Hello all, using a new Prisma setup (Prisma v7) I was able to get everything working.

I did notice that the issue mentions upgrading to Prisma v7, I wonder if the upgrade has anything to do with this?

If anyone has any important or helpful information please let me know!

<!-- gh-comment-id:3624252496 --> @ping-maxwell commented on GitHub (Dec 8, 2025): Hello all, using a new Prisma setup (Prisma v7) I was able to get everything working. I did notice that the issue mentions **upgrading to Prisma v7**, I wonder if the upgrade has anything to do with this? If anyone has any important or helpful information please let me know!
GiteaMirror commented 2026-04-17 19:05:00 -05:00
Author
Owner
Copy Link

@alexwork1611 commented on GitHub (Dec 8, 2025):

Hello all, using a new Prisma setup (Prisma v7) I was able to get everything working.

I did notice that the issue mentions upgrading to Prisma v7, I wonder if the upgrade has anything to do with this?

If anyone has any important or helpful information please let me know!

Hello,

Yes. I upgraded from Prisma 6.18 to 7.0. Reverting to Better Auth 1.3 resolved my issue. I don't know what else to mention.

<!-- gh-comment-id:3626389289 --> @alexwork1611 commented on GitHub (Dec 8, 2025): > Hello all, using a new Prisma setup (Prisma v7) I was able to get everything working. > > I did notice that the issue mentions **upgrading to Prisma v7**, I wonder if the upgrade has anything to do with this? > > If anyone has any important or helpful information please let me know! Hello, Yes. I upgraded from Prisma 6.18 to 7.0. Reverting to Better Auth 1.3 resolved my issue. I don't know what else to mention.
GiteaMirror commented 2026-04-17 19:05:01 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Dec 9, 2025):

How about schema migrations? Did you use the latest prisma schema generation from the @better-auth/cli? and did you re-generate when switching/upgrading versions?

<!-- gh-comment-id:3631052295 --> @ping-maxwell commented on GitHub (Dec 9, 2025): How about schema migrations? Did you use the latest prisma schema generation from the `@better-auth/cli`? and did you re-generate when switching/upgrading versions?
GiteaMirror commented 2026-04-17 19:05:01 -05:00
Author
Owner
Copy Link

@alexwork1611 commented on GitHub (Dec 10, 2025):

How about schema migrations? Did you use the latest prisma schema generation from the @better-auth/cli? and did you re-generate when switching/upgrading versions?

No, I did not do that. Thank you for letting me know. Preliminarily closing until finding out that using @better-auth/cli did not fix my issue.

<!-- gh-comment-id:3636608826 --> @alexwork1611 commented on GitHub (Dec 10, 2025): > How about schema migrations? Did you use the latest prisma schema generation from the `@better-auth/cli`? and did you re-generate when switching/upgrading versions? No, I did not do that. Thank you for letting me know. Preliminarily closing until finding out that using `@better-auth/cli` did not fix my issue.
GiteaMirror commented 2026-04-17 19:05:02 -05:00
Author
Owner
Copy Link

@alexwork1611 commented on GitHub (Dec 11, 2025):

@ping-maxwell

Hello,

So I generated the new Prisma schema.prisma file with Better Auth 1.4.6 and I see that there's a new @@map directive at the end, overriding the table in the database. I will use the Account Prisma model as the revelatory example.

Image

Is the @@map("account") the culprit for this issue? If I just specify the modelName inside the betterAuth config for each table, then I should be good, right?

Here's the config for the account Better Auth model.

Image

Checking right now if this change fixes my problems.

<!-- gh-comment-id:3640965223 --> @alexwork1611 commented on GitHub (Dec 11, 2025): @ping-maxwell Hello, So I generated the new Prisma `schema.prisma` file with Better Auth 1.4.6 and I see that there's a new `@@map` directive at the end, overriding the table in the database. I will use the `Account` Prisma model as the revelatory example. <img width="908" height="404" alt="Image" src="https://github.com/user-attachments/assets/80d88a22-e0cf-409b-ad06-cf24bd07b902" /> Is the `@@map("account")` the culprit for this issue? If I just specify the `modelName` inside the `betterAuth` config for each table, then I should be good, right? Here's the config for the `account` Better Auth model. <img width="362" height="104" alt="Image" src="https://github.com/user-attachments/assets/b9119e5c-5ee8-49bf-ba4b-3cd63869b7aa" /> Checking right now if this change fixes my problems.
GiteaMirror commented 2026-04-17 19:05:03 -05:00
Author
Owner
Copy Link

@alexwork1611 commented on GitHub (Dec 11, 2025):

How about schema migrations? Did you use the latest prisma schema generation from the @better-auth/cli? and did you re-generate when switching/upgrading versions?

After changing all the modelName props, I still cannot update my email using await authClient.changeEmail({ newEmail: email }).

Image Image Image

I am getting { status: true } as a response from http://localhost:3000/api/auth/change-email, but the email is not actually changing.

Image

@ping-maxwell, please help.

<!-- gh-comment-id:3641140902 --> @alexwork1611 commented on GitHub (Dec 11, 2025): > How about schema migrations? Did you use the latest prisma schema generation from the `@better-auth/cli`? and did you re-generate when switching/upgrading versions? After changing all the `modelName` props, I still cannot update my email using `await authClient.changeEmail({ newEmail: email })`. <img width="655" height="739" alt="Image" src="https://github.com/user-attachments/assets/2d574eaa-f39d-42b1-9d66-5096dd3b5882" /> <img width="564" height="130" alt="Image" src="https://github.com/user-attachments/assets/84e04a43-6396-482b-be4c-fcb4dfda7ae7" /> <img width="721" height="392" alt="Image" src="https://github.com/user-attachments/assets/40b43d59-4b94-4ede-a38b-ed1b9da0d5a5" /> I am getting `{ status: true }` as a response from `http://localhost:3000/api/auth/change-email`, but the email is not actually changing. <img width="894" height="132" alt="Image" src="https://github.com/user-attachments/assets/ce7805de-c877-4054-b587-16f316859b72" /> @ping-maxwell, please help.
GiteaMirror commented 2026-04-17 19:05:04 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Jan 6, 2026):

I think status: true from the change-email response means it called the sendVerificationEmail function from the auth config, which you would be able to get a URL from and then proceed from there, is that what you're doing?

<!-- gh-comment-id:3713418035 --> @ping-maxwell commented on GitHub (Jan 6, 2026): I think `status: true` from the change-email response means it called the `sendVerificationEmail` function from the auth config, which you would be able to get a URL from and then proceed from there, is that what you're doing?
GiteaMirror commented 2026-04-17 19:05:06 -05:00
Author
Owner
Copy Link

@alexwork1611 commented on GitHub (Jan 6, 2026):

I think status: true from the change-email response means it called the sendVerificationEmail function from the auth config, which you would be able to get a URL from and then proceed from there, is that what you're doing?

Yes, that's what I'm doing. I am sending an email to verify the new address.

<!-- gh-comment-id:3714066002 --> @alexwork1611 commented on GitHub (Jan 6, 2026): > I think `status: true` from the change-email response means it called the `sendVerificationEmail` function from the auth config, which you would be able to get a URL from and then proceed from there, is that what you're doing? Yes, that's what I'm doing. I am sending an email to verify the new address.
GiteaMirror commented 2026-04-17 19:05:08 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Jan 8, 2026):

Hello @alexwork1611 try enabling debugLogs to see if any DB actions go through during something like authClient.updateUser, then check it against your DB to ensure. Please send me the logs of it so I can debug further

prismaAdapter(client, {debugLogs: true})
<!-- gh-comment-id:3722903729 --> @ping-maxwell commented on GitHub (Jan 8, 2026): Hello @alexwork1611 try enabling debugLogs to see if any DB actions go through during something like authClient.updateUser, then check it against your DB to ensure. Please send me the logs of it so I can debug further ```ts prismaAdapter(client, {debugLogs: true}) ```
GiteaMirror commented 2026-04-17 19:05:09 -05:00
Author
Owner
Copy Link

@DevDuki commented on GitHub (Jan 9, 2026):

@ping-maxwell I am experiencing the same issue. In my case users don't have a verified email, so changing an email should happen instantly (at least that's how it's worked before). So I tried changing a user with the email 5@email.com to asdf@email.com. I get a success response as described by alex, but no changes happened.

This is what the debug logs show:

2026-01-09T10:28:07.343Z INFO [Better Auth]: [Prisma Adapter] #10 [1/3] findOne: {
  model: 'user',
  where: [
    {
      operator: 'eq',
      connector: 'AND',
      field: 'email',
      value: 'asdf@email.com'
    }
  ],
  select: undefined,
  join: undefined
}
2026-01-09T10:28:07.344Z INFO [Better Auth]: [Prisma Adapter] #10 [2/3] findOne (DB Result): { model: 'user', data: null }
2026-01-09T10:28:07.344Z INFO [Better Auth]: [Prisma Adapter] #10 [3/3] findOne (Parsed Result): { model: 'user', data: null }
2026-01-09T10:28:07.411Z INFO [Better Auth]: [Prisma Adapter] #11 [1/3] findMany: {
  model: 'account',
  where: [
    {
      operator: 'eq',
      connector: 'AND',
      field: 'userId',
      value: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3'
    }
  ],
  limit: 100,
  sortBy: undefined,
  offset: undefined,
  join: undefined
}
2026-01-09T10:28:07.412Z INFO [Better Auth]: [Prisma Adapter] #11 [2/3] findMany (DB Result): {
  model: 'account',
  data: [
    {
      id: 'B9LrMpAKihzIDNGzffR0irqdepkAhAVW',
      accountId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3',
      providerId: 'credential',
      userId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3',
      accessToken: null,
      refreshToken: null,
      idToken: null,
      accessTokenExpiresAt: null,
      refreshTokenExpiresAt: null,
      scope: null,
      password: '0ba6f64cd9073da3618f13b287489de1:415ef959feaec8db90d004d66859553777fb5c158a3484b86f5b997d470731b072c09edabd544dc71a7686c80a2c24655964a534c109342405ca3c0f32203b25',
      createdAt: 2025-12-13T18:41:54.172Z,
      updatedAt: 2025-12-13T18:41:54.172Z
    }
  ]
}
2026-01-09T10:28:07.412Z INFO [Better Auth]: [Prisma Adapter] #11 [3/3] findMany (Parsed Result): {
  model: 'account',
  data: [
    {
      accountId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3',
      providerId: 'credential',
      userId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3',
      accessToken: null,
      refreshToken: null,
      idToken: null,
      accessTokenExpiresAt: null,
      refreshTokenExpiresAt: null,
      scope: null,
      password: '0ba6f64cd9073da3618f13b287489de1:415ef959feaec8db90d004d66859553777fb5c158a3484b86f5b997d470731b072c09edabd544dc71a7686c80a2c24655964a534c109342405ca3c0f32203b25',
      createdAt: 2025-12-13T18:41:54.172Z,
      updatedAt: 2025-12-13T18:41:54.172Z,
      id: 'B9LrMpAKihzIDNGzffR0irqdepkAhAVW'
    }
  ]
}
<!-- gh-comment-id:3728335050 --> @DevDuki commented on GitHub (Jan 9, 2026): @ping-maxwell I am experiencing the same issue. In my case users don't have a verified email, so changing an email should happen instantly (at least that's how it's worked before). So I tried changing a user with the email `5@email.com` to `asdf@email.com`. I get a success response as described by alex, but no changes happened. This is what the debug logs show: ``` 2026-01-09T10:28:07.343Z INFO [Better Auth]: [Prisma Adapter] #10 [1/3] findOne: { model: 'user', where: [ { operator: 'eq', connector: 'AND', field: 'email', value: 'asdf@email.com' } ], select: undefined, join: undefined } 2026-01-09T10:28:07.344Z INFO [Better Auth]: [Prisma Adapter] #10 [2/3] findOne (DB Result): { model: 'user', data: null } 2026-01-09T10:28:07.344Z INFO [Better Auth]: [Prisma Adapter] #10 [3/3] findOne (Parsed Result): { model: 'user', data: null } 2026-01-09T10:28:07.411Z INFO [Better Auth]: [Prisma Adapter] #11 [1/3] findMany: { model: 'account', where: [ { operator: 'eq', connector: 'AND', field: 'userId', value: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3' } ], limit: 100, sortBy: undefined, offset: undefined, join: undefined } 2026-01-09T10:28:07.412Z INFO [Better Auth]: [Prisma Adapter] #11 [2/3] findMany (DB Result): { model: 'account', data: [ { id: 'B9LrMpAKihzIDNGzffR0irqdepkAhAVW', accountId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3', providerId: 'credential', userId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3', accessToken: null, refreshToken: null, idToken: null, accessTokenExpiresAt: null, refreshTokenExpiresAt: null, scope: null, password: '0ba6f64cd9073da3618f13b287489de1:415ef959feaec8db90d004d66859553777fb5c158a3484b86f5b997d470731b072c09edabd544dc71a7686c80a2c24655964a534c109342405ca3c0f32203b25', createdAt: 2025-12-13T18:41:54.172Z, updatedAt: 2025-12-13T18:41:54.172Z } ] } 2026-01-09T10:28:07.412Z INFO [Better Auth]: [Prisma Adapter] #11 [3/3] findMany (Parsed Result): { model: 'account', data: [ { accountId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3', providerId: 'credential', userId: '9ShddLZjK3gvkQApOv8vvP3V8xrXzYF3', accessToken: null, refreshToken: null, idToken: null, accessTokenExpiresAt: null, refreshTokenExpiresAt: null, scope: null, password: '0ba6f64cd9073da3618f13b287489de1:415ef959feaec8db90d004d66859553777fb5c158a3484b86f5b997d470731b072c09edabd544dc71a7686c80a2c24655964a534c109342405ca3c0f32203b25', createdAt: 2025-12-13T18:41:54.172Z, updatedAt: 2025-12-13T18:41:54.172Z, id: 'B9LrMpAKihzIDNGzffR0irqdepkAhAVW' } ] } ```
GiteaMirror commented 2026-04-17 19:05:09 -05:00
Author
Owner
Copy Link

@DevDuki commented on GitHub (Jan 9, 2026):

Ah I see what's going on! The change happens only after the user verifies their new email. But that's not how it's supposed work is it? What I expect is the following flow (and it's also how it was before).

Case 1 before - Email not verified:

  • User requests an email change
  • I call auth.api.changeEmail with their new email
  • User's email is changed instantly
  • User receives a mail to their new email to verify it (in my case this is optional! Users don't require to have a verified email to use my application)

Case 2 before - Email is verified:

  • User request an email change
  • I call auth.api.changeEmail with their new email
  • User first receives an email on their current email asking if they really want to change their email
  • User clicks on the link in that email
  • User's email is changed
  • User receives an other email on their new email to verify (here again in my case that is optional)

However the flow right now works quite different and I think it's a regression, because in my use case where users don't necessarily need a verified email it looks broken.

Case 1 now - Email not verified:

  • User requests an email change
  • I call auth.api.changeEmail with their new email
  • User's email is not changed instantly
  • User receives an email to their new email to verify it (in my case this is supposed to be optional, but now suddenly it's mandatory)
  • User's email is only changed when clicking the link in the email sent to their new email

Case 2 now - Email is verified:

  • User request an email change
  • I call auth.api.changeEmail with their new email
  • User first receives an email on their current email asking if they really want to change their email
  • User clicks on the link in that email
  • User's email is still not changed
  • User receives an other email on their new email to verify (here again in my case that is optional)
  • Now the user's email is changed
<!-- gh-comment-id:3728395615 --> @DevDuki commented on GitHub (Jan 9, 2026): Ah I see what's going on! The change happens only after the user verifies their new email. But that's not how it's supposed work is it? What I expect is the following flow (and it's also how it was before). Case 1 before - Email not verified: - User requests an email change - I call `auth.api.changeEmail` with their new email - User's email is changed instantly - User receives a mail to their new email to verify it (in my case this is optional! Users don't require to have a verified email to use my application) Case 2 before - Email is verified: - User request an email change - I call `auth.api.changeEmail` with their new email - User first receives an email on their current email asking if they really want to change their email - User clicks on the link in that email - User's email is changed - User receives an other email on their new email to verify (here again in my case that is optional) However the flow right now works quite different and I think it's a regression, because in my use case where users don't necessarily need a verified email it looks broken. Case 1 now - Email not verified: - User requests an email change - I call `auth.api.changeEmail` with their new email - User's email is not changed instantly - User receives an email to their new email to verify it (in my case this is supposed to be optional, but now suddenly it's mandatory) - User's email is only changed when clicking the link in the email sent to their new email Case 2 now - Email is verified: - User request an email change - I call `auth.api.changeEmail` with their new email - User first receives an email on their current email asking if they really want to change their email - User clicks on the link in that email - User's email is still not changed - User receives an other email on their new email to verify (here again in my case that is optional) - Now the user's email is changed
GiteaMirror commented 2026-04-17 19:05:10 -05:00
Author
Owner
Copy Link

@DevDuki commented on GitHub (Jan 9, 2026):

I just read up in the docs and noticed that this behaviour has changed! In fact it's been changed in this PR. I can't find out in which version this PR has been released, but why have breaking changes like these not been marked as breaking changes in the release notes? I think that's the issue in my case, not sure if it's the same for you @alexwork1611

<!-- gh-comment-id:3728434668 --> @DevDuki commented on GitHub (Jan 9, 2026): I just read up in the docs and noticed that this behaviour has changed! In fact it's been changed in this [PR](https://github.com/better-auth/better-auth/pull/6088). I can't find out in which version this PR has been released, but why have breaking changes like these not been marked as breaking changes in the release notes? I think that's the issue in my case, not sure if it's the same for you @alexwork1611
GiteaMirror commented 2026-04-17 19:05:13 -05:00
Author
Owner
Copy Link

@DevDuki commented on GitHub (Jan 9, 2026):

I did the refactoring and it works fine for unverified emails now.

But for users that already have a verified email, their email only changes after they both clicked on the link in the "Confirm email change" email AND the "verify new email" email. Why are verified emails forced to verify their new email after they already confirmed the email change in the "Confirm email change" email?
Especially when I don't have requireEmailVerification set to true in my configs.

<!-- gh-comment-id:3728464681 --> @DevDuki commented on GitHub (Jan 9, 2026): I did the refactoring and it works fine for unverified emails now. But for users that already have a verified email, their email only changes after they both clicked on the link in the "Confirm email change" email AND the "verify new email" email. Why are verified emails forced to verify their new email after they already confirmed the email change in the "Confirm email change" email? Especially when I don't have `requireEmailVerification` set to true in my configs.
GiteaMirror commented 2026-04-17 19:05:13 -05:00
Author
Owner
Copy Link

@Besufikad17 commented on GitHub (Jan 28, 2026):

This is a known issue when using Better Auth v1.4.4 with Prisma v7. Prisma v7 introduced breaking changes that the Better Auth CLI and schema generator do not yet fully support, which can cause update operations (like authClient.updateUser() and authClient.changeEmail()) to silently fail—returning success but not actually updating the database. This typically happens if the Prisma schema, config, or import paths are not manually updated after each CLI run, or if unique constraints and model/field names do not match exactly between your schema and Better Auth config details details.

To work around this until full Prisma v7 support lands:

  1. After running the Better Auth CLI, manually update your Prisma schema:

    • Move connection settings (url, directUrl, shadowDatabaseUrl) from schema.prisma to a new prisma.config.ts file.
    • Change the generator provider from "prisma-client-js" to "prisma-client".
    • Update your import paths to use the generated client (e.g., import { PrismaClient } from "@/generated/prisma/client").
    • Explicitly use the correct Prisma adapter package (like @prisma/adapter-pg for PostgreSQL) reference reference.

  2. Double-check that all model and field names in your Better Auth config exactly match your Prisma schema, and that all fields used in where clauses (especially id) are marked as @unique in your schema reference.

  3. Enable debug logging in your adapter to catch any silent errors.

  4. Repeat these manual schema/config updates after every CLI run, as the CLI will overwrite them.

There is no automated fix yet, but maintainers are aware and working on full Prisma v7 support. Until then, these manual steps are required to avoid silent failures in update operations reference reference.

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

Based on this response I enabled log of my prisma client and I am not getting any UPDATE queries in the log when changeEmail is called. I am using better-auth ^1.4.12 with prisma v7

<!-- gh-comment-id:3811542277 --> @Besufikad17 commented on GitHub (Jan 28, 2026): > This is a known issue when using Better Auth v1.4.4 with Prisma v7. Prisma v7 introduced breaking changes that the Better Auth CLI and schema generator do not yet fully support, which can cause update operations (like `authClient.updateUser()` and `authClient.changeEmail()`) to silently fail—returning success but not actually updating the database. This typically happens if the Prisma schema, config, or import paths are not manually updated after each CLI run, or if unique constraints and model/field names do not match exactly between your schema and Better Auth config [details](https://github.com/better-auth/better-auth/issues/6354) [details](https://github.com/better-auth/better-auth/issues/6277). > > **To work around this until full Prisma v7 support lands:** > > 1. After running the Better Auth CLI, manually update your Prisma schema: > > * Move connection settings (`url`, `directUrl`, `shadowDatabaseUrl`) from `schema.prisma` to a new `prisma.config.ts` file. > * Change the generator provider from `"prisma-client-js"` to `"prisma-client"`. > * Update your import paths to use the generated client (e.g., `import { PrismaClient } from "@/generated/prisma/client"`). > * Explicitly use the correct Prisma adapter package (like `@prisma/adapter-pg` for PostgreSQL) [reference](https://github.com/better-auth/better-auth/issues/6277) [reference](https://github.com/better-auth/better-auth/issues/6112). > 2. Double-check that all model and field names in your Better Auth config exactly match your Prisma schema, and that all fields used in `where` clauses (especially `id`) are marked as `@unique` in your schema [reference](https://github.com/better-auth/better-auth/issues/2114). > 3. Enable debug logging in your adapter to catch any silent errors. > 4. Repeat these manual schema/config updates after every CLI run, as the CLI will overwrite them. > > There is no automated fix yet, but maintainers are aware and working on full Prisma v7 support. Until then, these manual steps are required to avoid silent failures in update operations [reference](https://github.com/better-auth/better-auth/issues/6354) [reference](https://github.com/better-auth/better-auth/issues/6277). > > _To reply, just mention [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/609c929f-2e56-4d41-81b3-10ffa63153fe?feedback_type=other) > > [![Chat with Dosu](https://camo.githubusercontent.com/7c571478962a6b8a5d47cac74b6824c75e4f6731bba52377e6007f9150462923/68747470733a2f2f646f73752e6465762f646f73752d636861742d62616467652e737667)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github) [![Open in Cursor](https://camo.githubusercontent.com/bdf7dbded65ee585887f47e5fd6fa099ea0933088b4b03d02e83b4def50154d4/68747470733a2f2f646f73752e6465762f646f73752d696e2d637572736f722e737667)](https://cursor.com/link/prompt?text=This%20is%20a%20known%20issue%20when%20using%20Better%20Auth%20v1.4.4%20with%20Prisma%20v7.%20Prisma%20v7%20introduced%20breaking%20changes%20that%20the%20Better%20Auth%20CLI%20and%20schema%20generator%20do%20not%20yet%20fully%20support%2C%20which%20can%20cause%20update%20operations%20%28like%20%60authClient.updateUser%28%29%60%20and%20%60authClient.changeEmail%28%29%60%29%20to%20silently%20fail%E2%80%94returning%20success%20but%20not%20actually%20updating%20the%20database.%20This%20typically%20happens%20if%20the%20Prisma%20schema%2C%20config%2C%20or%20import%20paths%20are%20not%20manually%20updated%20after%20each%20CLI%20run%2C%20or%20if%20unique%20constraints%20and%20model/field%20names%20do%20not%20match%20exactly%20between%20your%20schema%20and%20Better%20Auth%20config%C2%A0%5Bdetails%5D%28https%3A//github.com/better-auth/better-auth/issues/6354%29%C2%A0%5Bdetails%5D%28https%3A//github.com/better-auth/better-auth/issues/6277%29.%0A%0A%2A%2ATo%20work%20around%20this%20until%20full%20Prisma%20v7%20support%20lands%3A%2A%2A%0A%0A1.%20After%20running%20the%20Better%20Auth%20CLI%2C%20manually%20update%20your%20Prisma%20schema%3A%0A%20%20%20-%20Move%20connection%20settings%20%28%60url%60%2C%20%60directUrl%60%2C%20%60shadowDatabaseUrl%60%29%20from%20%60schema.prisma%60%20to%20a%20new%20%60prisma.config.ts%60%20file.%0A%20%20%20-%20Change%20the%20generator%20provider%20from%20%60%22prisma-client-js%22%60%20to%20%60%22prisma-client%22%60.%0A%20%20%20-%20Update%20your%20import%20paths%20to%20use%20the%20generated%20client%20%28e.g.%2C%20%60import%20%7B%20PrismaClient%20%7D%20from%20%22%40/generated/prisma/client%22%60%29.%0A%20%20%20-%20Explicitly%20use%20the%20correct%20Prisma%20adapter%20package%20%28like%20%60%40prisma/adapter-pg%60%20for%20PostgreSQL%29%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6277%29%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6112%29.%0A2.%20Double-check%20that%20all%20model%20and%20field%20names%20in%20your%20Better%20Auth%20config%20exactly%20match%20your%20Prisma%20schema%2C%20and%20that%20all%20fields%20used%20in%20%60where%60%20clauses%20%28especially%20%60id%60%29%20are%20marked%20as%20%60%40unique%60%20in%20your%20schema%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/2114%29.%0A3.%20Enable%20debug%20logging%20in%20your%20adapter%20to%20catch%20any%20silent%20errors.%0A4.%20Repeat%20these%20manual%20schema/config%20updates%20after%20every%20CLI%20run%2C%20as%20the%20CLI%20will%20overwrite%20them.%0A%0AThere%20is%20no%20automated%20fix%20yet%2C%20but%20maintainers%20are%20aware%20and%20working%20on%20full%20Prisma%20v7%20support.%20Until%20then%2C%20these%20manual%20steps%20are%20required%20to%20avoid%20silent%20failures%20in%20update%20operations%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6354%29%C2%A0%5Breference%5D%28https%3A//github.com/better-auth/better-auth/issues/6277%29.) [![Join Discord](https://camo.githubusercontent.com/7d2066700925db1e370d956834f9ea0e5bc92cecbe84963fbd2a363e45091b4e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d)](https://go.dosu.dev/discord-bot) [![Share on X](https://camo.githubusercontent.com/a8bd7f3fcf3f5e3bd124eee9ae50ae2ac17b40971726665ac2121d48f9aee155/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/6469) Based on this response I enabled log of my prisma client and I am not getting any UPDATE queries in the log when `changeEmail` is called. I am using better-auth `^1.4.12` with prisma v7
GiteaMirror commented 2026-04-17 19:05:15 -05:00
Author
Owner
Copy Link

@DevDuki commented on GitHub (Mar 2, 2026):

@ping-maxwell any explanation regarding the new behavior I mentioned here?

<!-- gh-comment-id:3985271107 --> @DevDuki commented on GitHub (Mar 2, 2026): @ping-maxwell any explanation regarding the new behavior I mentioned [here](https://github.com/better-auth/better-auth/issues/6469#issuecomment-3728464681)?
GiteaMirror commented 2026-04-17 19:05:16 -05:00
Author
Owner
Copy Link

@alexwork1611 commented on GitHub (Apr 4, 2026):

This is still an issue with the latest Better Auth version (1.5.6).

P.S.: I had to downgrade to 1.3.34 to make it work again.

<!-- gh-comment-id:4186589822 --> @alexwork1611 commented on GitHub (Apr 4, 2026): This is still an issue with the latest Better Auth version ([1.5.6](https://www.npmjs.com/package/better-auth/v/1.5.6)). P.S.: I had to downgrade to 1.3.34 to make it work again.
GiteaMirror commented 2026-04-17 19:05:17 -05:00
Author
Owner
Copy Link

@alexwork1611 commented on GitHub (Apr 7, 2026):

Same issue in 1.6.0.

<!-- gh-comment-id:4197207483 --> @alexwork1611 commented on GitHub (Apr 7, 2026): Same issue in 1.6.0.
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 database
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#27848
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?