Add safeguard for MigrateAsync with targetMigration

[Ben555555]

We are using the following code to run each migration one by one, so we can better determine which migration failed:

                var pendingMigrations = await dbContext.Database.GetPendingMigrationsAsync(cancellationToken);

                var migrator = dbContext.Database.GetInfrastructure().GetRequiredService<IMigrator>();

                foreach (string migration in pendingMigrations)
                {
                    logger.LogInformation($"Applying migration '{migration}'...");

                    await migrator.MigrateAsync(migration, cancellationToken);
                }

Recently when we deployed an application we noticed an unfamiliar behaviour. A field disappeared and was gone after the migrations were executed.
It turned out that for one migration, the Down-Migration was called, because that migration was already deployed and had a higher timestamp in the filename than the pending migrations. This happened because the migration was added on a branch that was going live, while on a dev branch already new migrations were added before.
So when the first pending migration was executed via IMigrator.MigrateAsync, the down migration of that already deployed migration was called. As far as I understand this is to make sure that the migrations always run on the "correct" state of the database.
In our case this caused an issue because the Down-Migration was called, but the Up-Migration was never called again. I assume this is because we use the migrator to explicitly execute migrations and it doesn't know when the last migration was done. I also assume this works correctly with the usual Database.MigrateAsync() method.

So my questions are:

• Is it even safe to use IMigrator.MigrateAsync, when it can implicitly call down migrations but in the end will never call the Up migration again?
• Is there a way we can ensure that the Up-Migration is executed in the end?
• Is this behaviour even documented somewhere? It took a lot of time to figure out why a field was deleted.

Include provider and version information

EF Core version:
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET 8.0
Operating system: Windows 11
IDE: Visual Studio 2022

[AndriySvyryd]

Is it even safe to use IMigrator.MigrateAsync, when it can implicitly call down migrations but in the end will never call the Up migration again?

It isn't safe to do it like in the code snippet provided. MigrateAsync was designed to be called once per session, with the target migration you'd want as the final state for your database.

We can add a parameter that would make Migrate throw if any migration would be reverted or if a migration to be applied is older than the newest applied migration.

Also, there are already logging events for when each migration is applied.

Is there a way we can ensure that the Up-Migration is executed in the end?

MigrateAsync will only call Up or Down for any particular migration in a single call. The logic it uses is fairly straightforward:

• It calls Up for any unapplied migration older than the target migration
• It calls Down for any applied migration newer than the target migration

Is this behaviour even documented somewhere? It took a lot of time to figure out why a field was deleted.

No, filed dotnet/EntityFramework.Docs#4824

[jedinja]

I just hit that same problem.

My use-case is that I want to run 400 migrations for a specific schema in a database, but this completely locks the database so our app cannot use the other schema-s meanwhile.

So I tried to run them one-by-one with a delay, which solved the problem.

But hit this issue instead.

The complete lack of tools (interface) to operate the db/migrations in a way that we want is appalling.

In a world where code is shared and developed independently, why would I need to completely downgrade my db, so I can run a migration I just received in my code.

It's obvious that the tools are existing for this to work (calling the migrateAsync method without parameters avoids the issue) but those tools/interface is not available for us to solve real-world issues.

Possible solutions that would solve our problems: give us access to a method that would run a migration without trying to do extra stuff and make extra checks; give us a hook, so we can insert our own code between every migration, like Task.Delay or logging or something entirely different.