prisma: Migration dev error

Bug description

Hi,

When doing a migrate dev after a successful migration I’ve got this error

Database error code: 1146

Database error:
Table 'prisma_migrate_shadow_db_530924f1-71bc-41c3-97ed-dc1a6a373b37.versions_old' doesn't exist

But I don’t have this table in my db

Complete error log

Error: P3006

Migration `20220206213143_remove_versions_old` failed to apply cleanly to the shadow database. 
Error code: P3018
Error:
A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 20220206213143_remove_versions_old

Database error code: 1146

Database error:
Table 'prisma_migrate_shadow_db_530924f1-71bc-41c3-97ed-dc1a6a373b37.versions_old' doesn't exist

Please check the query number 1 from the migration file.

And the migration file looks like this

/*
  Warnings:

  - You are about to drop the `versions_old` table. If the table is not empty, all the data it contains will be lost.

*/
-- DropForeignKey
ALTER TABLE `versions_old` DROP FOREIGN KEY `versions_old_ibfk_2`;

-- DropForeignKey
ALTER TABLE `versions_old` DROP FOREIGN KEY `versions_old_ibfk_3`;

-- DropTable
DROP TABLE `versions_old`;

but has already been applied without any issue (I’ve removed a table)

How to reproduce

Expected behavior

Migrate without any issue

Prisma information

Environment & setup

  • OS: Mac Os
  • Database: Mysql 8.0.22
  • Node.js version: v16.13.0

Prisma Version

prisma                  : 3.9.1
@prisma/client          : 3.9.1
Current platform        : darwin
Query Engine (Node-API) : libquery-engine bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : bcc2ff906db47790ee902e7bbc76d7ffb1893009
Studio                  : 0.457.0

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 28 (12 by maintainers)

Most upvoted comments

init comes after 2022121718162_..., 0_init comes before - that is what caused the problem. For a while we had a bug in our docs that we told people to use init - we changed that to 0_init. Now everything should work when you follow the documentation.

This just happened to me, the problem was that I baselined my migrations with the name “init”, then when a second migration was created it had the current date as a prefix “2022121718162_…” When the shadow database tried running the migrations, it started with the second one, thus not finding a table because it wasn’t yet created.

Renaming the baseline with “2021_init” solved the problem.

This just happened to me, the problem was that I baselined my migrations with the name “init”, then when a second migration was created it had the current date as a prefix “2022121718162_…” When the shadow database tried running the migrations, it started with the second one, thus not finding a table because it wasn’t yet created.

Renaming the baseline with “2021_init” solved the problem.

Wohooo, this is ridiculous, I had also named my initial baselined migration as init, and I was getting the shadow table error. Your comment has turned out to be a savior, Cheers! This looks like a bug. @janpio can you look into this?

Last update and I’ll close the ticket.

I’ve choose an another path (one that was accessible for me in term of knowledge).

  • backed up my prod db content only
  • delete all prisma migratation history and started over
  • generated the db in local based on the schema
  • imported the db content in local
  • exported my local db to prod

And it worked.

It cost me a few minutes of downtime but it was way simpler for me.

I still cannot explain why I’ve had this issue but I’m glad this is over (🤞)

The error message is different in your last comment. Would you be comfortable sharing the 20220209213808_ migration? (it’s not the one about version_old).