W
Wasp•5w ago
spm

PrismaClientKnownRequestError: The table `public.User` does not exist in the current database.

Hi, Wasp team. I deployed my project to Fly.io though the CLI commands, and added secrets required for the app to run. I try to signup a user within the app and end up getting the following error: 
PrismaClientKnownRequestError:
Invalid `prisma.user.count()` invocation:
The table `public.User` does not exist in the current database.

at Ln.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:121:7753)
 at Ln.handleAndLogRequestError (/app/node_modules/@prisma/client/runtime/library.js:121:7061)
 at Ln.request (/app/node_modules/@prisma/client/runtime/library.js:121:6745)
 at async l (/app/node_modules/@prisma/client/runtime/library.js:130:9633)
 at async onBeforeSignup (/app/src/auth/hooks.ts:26:17)
 at async signup (/app/.wasp/build/server/src/auth/providers/username/signup.ts:37:7) {
 code: 'P2021',
 clientVersion: '5.19.1',
 meta: { modelName: 'User', table: 'public.User' } }
🐝 This error can happen if you did't run the database migrations. 
PrismaClientKnownRequestError:
Invalid `prisma.user.count()` invocation:
The table `public.User` does not exist in the current database.

at Ln.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:121:7753)
 at Ln.handleAndLogRequestError (/app/node_modules/@prisma/client/runtime/library.js:121:7061)
 at Ln.request (/app/node_modules/@prisma/client/runtime/library.js:121:6745)
 at async l (/app/node_modules/@prisma/client/runtime/library.js:130:9633)
 at async onBeforeSignup (/app/src/auth/hooks.ts:26:17)
 at async signup (/app/.wasp/build/server/src/auth/providers/username/signup.ts:37:7) {
 code: 'P2021',
 clientVersion: '5.19.1',
 meta: { modelName: 'User', table: 'public.User' } }
🐝 This error can happen if you did't run the database migrations.
I have run multiple wasp cleans and several redeployments. However, the issue still persist. I also tried to ssh to the server and manually deploy the schema using: npx prisma migrate deploy However, this gives me the following Error: 
Error: Could not find Prisma Schema that is required for this command.
You can either provide it with `--schema` argument, set it as `prisma.schema` in your package.json or put it into the default location.
Checked following paths:

schema.prisma: file not found
prisma/schema.prisma: file not found
prisma/schema: directory not found

See also https://pris.ly/d/prisma-schema-location
Error: Could not find Prisma Schema that is required for this command.
You can either provide it with `--schema` argument, set it as `prisma.schema` in your package.json or put it into the default location.
Checked following paths:

schema.prisma: file not found
prisma/schema.prisma: file not found
prisma/schema: directory not found

See also https://pris.ly/d/prisma-schema-location
The schema.prisma does not seem to be even pushed to the deployment container. I only followed the standard CLI commands for deployment.
3 Replies
kapa.ai
kapa.ai•5w ago
Hi @spm. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- The error you're seeing, PrismaClientKnownRequestError: The table public.User does not exist in the current database, typically means that the database migrations have not been applied to your production database on Fly.io. This results in the required tables (like User) not being present, so Prisma cannot perform queries on them. From your description and the error message when running npx prisma migrate deploy, it appears that the Prisma schema file (schema.prisma) is not present in your deployed container. This is a known issue that can occur if migrations are not run or if the schema file is not included in the build/deploy process. Key points from the knowledge sources: - You must run wasp db migrate-dev locally before deploying, to ensure migrations are created and the Prisma client is generated. If you skip this, your production database will not have the necessary tables, and you may not have any migration files to apply on production. This is a common cause of the error you're seeing. The migration files are generated from your local schema and then included in the deployment artifact. If you never ran wasp db migrate-dev, there are no migrations to apply on production, and thus no tables like User exist in the production DB.
See: Discord support thread on running migrations - The error about missing schema.prisma during prisma migrate deploy on the server is expected if the schema file is not copied into the Docker image or deployment artifact. Wasp's deployment process should handle this, but if you never ran migrations locally, the necessary files may not be present.
See: Github Issue #215 - The correct workflow is: 1. Run wasp db migrate-dev locally. This generates migration files and the Prisma client. 2. Deploy your app using the Wasp CLI. The migration files are included in the deployment. 3. On deployment, Wasp (or your CI) should run prisma migrate deploy to apply migrations to the production database. - If you never ran wasp db migrate-dev locally, there will be no migrations to apply, and your production DB will be empty (no tables).
See: Discord support thread, "One thing I noticed in your repository is that you don't have any migrations. This leads me to believe you never ran the wasp db migrate-dev" What you should do: 1. Locally, run: 
   wasp db migrate-dev
   
   wasp db migrate-dev
This will generate the necessary migration files and Prisma client based on your entities. 2. Redeploy your app using the Wasp CLI. This will include the migration files in the deployment. 3. On Fly.io, the migrations should be applied automatically (or you can run the migration command as part of your deployment process if needed). If you follow these steps, your production database should have the required tables, and the error should be resolved. If you have already run wasp db migrate-dev locally and are still seeing this issue, double-check that the migration files exist in your project (typically under a migrations directory) and that they are being included in the deployment artifact. If you continue to have issues, please ensure you are using the latest version of Wasp and refer to the Wasp deployment documentation for more details. --- Summary:
You need to run wasp db migrate-dev locally before deploying. This generates the migration files that are then applied to your production database, creating the necessary tables. If you skip this step, your production DB will be empty, and you'll see the error about missing tables.
Reference: Discord support thread on running migrations ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @spm, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
spm
spmOP•5w ago
I have been running wasp db migrate-dev locally before deployment. However, the issue still persists. I doubled checked and there is a schema.prisma file in the /build/db folder with the following content: 
$ cat schema.prisma

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id                            String               @id @default(uuid())
  createdAt                     DateTime             @default(now())
  email                         String?              @unique
  username                      String?              @unique
  isAdmin                       Boolean              @default(false)
  paymentProcessorUserId        String?              @unique
  ...
}
$ cat schema.prisma

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id                            String               @id @default(uuid())
  createdAt                     DateTime             @default(now())
  email                         String?              @unique
  username                      String?              @unique
  isAdmin                       Boolean              @default(false)
  paymentProcessorUserId        String?              @unique
  ...
}
martinsos
martinsos•4w ago
Yeah so Wasp generates prisma.schema for you, in .wasp/build in this case when you are deploying. And when dpeloying to Fly via wasp CLI, that schema will get applied to the DB on the Fly, so you should have those tables in there (table User). Sounds like for some reason something went wrong there, and up there on the database on the Fly, that User table didn't get created. And if all went fine with deployment, it should have been. 1. What happens if you try deploying again, with wasp CLI? wasp deploy fly deploy? What is the output? 2. What if you go to Fly, delete the database, and then try deploying again with wasp CLI? wasp deploy fly deploy? What is the output then? 3. If none of these helps, we can also try deleting client, server and db on Fly, and try again from scratch with wasp deploy fly launch. Make sure to capture all the output, and if there is still an issue, we will take a detailed look at that output.

Did you find this page helpful?