The migration 20210501202953_name_of_previous_migration was modified after it was applied

[kivi]

Bug description

When I try to run migrations after changes in the schema file, I am getting almos always an error message:
The migration ... was modified after it was applied.

I can continue but I will loose all data after confirming resetting the database.

How to reproduce

I am using Blitz.js with Prisma, so the command looks a bit different.

I change the shema.prisma file.
Then I run migration dev with prisma cli tool in PowerShell

blitz prisma migrate dev --create-only

And I have the same issue, with:
npx prisma migrate dev

Expected behavior

The migration files should be created with no warnings and without suggesting to reset the database. Without this message: We need to reset the PostgreSQL database

Prisma information

The change I made in a model.

model Event {
  id                   Int                    @id @default(autoincrement())
  createdAt            DateTime               @default(now())
  updatedAt            DateTime               @updatedAt
  title                String
  titleShort           String?

.....

+ private              Boolean                @default(true)
  published            Boolean                @default(false)

....
}

Environment & setup

• OS: Windows, PowerShell
• Database: PostgreSQL 12
• Node.js version: v15.8.0 (I think I hade same issues with v14.x)
• Prisma version: windows / 2.21.2

prisma               : 2.21.2
@prisma/client       : 2.21.2
Current platform     : windows
Query Engine         : query-engine e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\query-engine-windows.exe)
Migration Engine     : migration-engine-cli e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine : introspection-core e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary        : prisma-fmt e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules\prisma\node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash : e421996c87d5f3c8f7eeadd502d4ad402c89464d
Studio               : 0.371.0
Preview Features     : orderByRelation

[janpio]

Can you please describe the steps we need to follow to get to the same situation? The problem here is that it tells you The migration ... was modified after it was applied although you did not do that. Everything that comes after is a result of that problem.

[kivi]

As I said I just changed the schema and added a Boolean field with a default value to the model and ran prisma migrate dev

And I just tried with a new Blitz app and added a String without default and as expected I am seeing the following message

Error: 
⚠️ We found changes that cannot be executed:

  • Step 1 Added the required column `street` to the `User` table without a default 
value. There are 1 rows in this table, it is not possible to execute this step.     

You can use prisma migrate dev --create-only to create the migration file, and manually modify it to address the underlying issue(s).
Then run prisma migrate dev to apply it and verify it works.

When I add field with default, like this: active Boolean @default(false) then the migration works fine. So it works fine for a newly created Blitz app with prisma dependency in package.json: "prisma": "~2.20",

Out put of prisma version:

npx prisma version
Environment variables loaded from .env
prisma               : 2.20.1
@prisma/client       : 2.20.1
Current platform     : windows

But with my production code and prisma Version: 2.21.2 I am still experiencing the error as described before.

I am wondering the detection of modification is implemented? Is checking the checksum of the migration file or something like that? If so, then autoformat or changing from CR to LF could also trigger that modification detection.

Soon I will write and test after I downgraded to 2.20.1

Thanks for reviewing this issue!

[kivi]

I had slightly modify the schema to downgrade from 2.21.2 to be able to see same message on 2.20.1

? The migration `20210501202953_consent_newsletter_flag_in_profile` was modified after it was applied.

Content of that migration file is:

-- CreateEnum
CREATE TYPE "ConsentType" AS ENUM ('NEWSLETTER', 'TERMS');

-- AlterTable
ALTER TABLE "UserConsent" ADD COLUMN     "ip" TEXT;

-- AlterTable
ALTER TABLE "Userprofile" ADD COLUMN     "newsletter" BOOLEAN NOT NULL DEFAULT false;

And I checked the database. This changes were already applied as I had already run this migration before. My new change is adding a boolean field with default value to another model. Which causes the problem in both versions I have testet so far.

Any idea how I could possibly continue? Maybe somehow tell prisma client to ignore this modification?

Or should I just delete all migrations? To make it easy to keep the data and create new migrations?

[pantharshit00]

@kivi Can you share your the contents of your migrations folder? I wasn't able to reproduce this in 2.24.0-dev.26

[kivi]

Hi @pantharshit00,

sorry can not share content of my migrations directory.

I almost sure it is the checksum, that is saved in migrations table that differs after committing oder pulling from repository.
Line breaks result in CR/LF by saving of a text file on Windows.
Depending on Git settings, line breaks can be transformed to LF.

I think a pragmatic approach could be that the file get's created with LF only.
And Prisma might adds an .gitattribures file with

* text=auto eol=lf
*.{png,jpg,jpeg,gif,webp,woff,woff2} binary

More details about gitattributes: https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/#autocrlf-true

Here is how could be reproduced:

Change git config autocrlf to autocrlf=true.
Make sure you made this change to be able to reproduce with git config list

1. change schema.prisma
2. prisma migrate dev --create-only
3. check the eol of file, I see LF
4. commit on a test branch
5. delete the file
6. and checkout again
7. check eol of file, I see CRLF

Now you can run migrate again or you can guess the checksum of the file has changed and therefore we will get the the error ... was modiefied ...

Suggestion

Why I suggesting a pragmatic solution? I guess most Users are using a modern tool like vsCode and they can handle LF as good as CRLF. But I have set autocrlf based on some documentations about Formatting and Whitespaces: https://www.git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

So prompting to add .gitattributes with that fix while running prisma migrate for Windows users could prevent this errors or at least this should be documented.

[randolphpark]

thanks @kivi. It saved me massive time.

I used dos2unix prisma/<../migrationfile.sql> fixed the file. With LF eol, it is happy with migration.

[pantharshit00]

I will close this in favour of #7101

Thanks for reporting everyone