Rollback migrations in parallel development?

Question

Database

I have a question about database migrations. Now there are various tools for this, but nowhere is the solution of the following case described:
the developer started to cut feature 1 and added migration 1, after him another developer started to cut feature 2, and made migration 2 finished the feature and it went to the master. After that, the first developer finished his feature and she also went to the master. Thus, the features were rolled out in the order - 2.1, and the migrations are sorted by timestamps, i.e. migrations will still be 1.2. If suddenly, feature number 1 turned out to be unfinished and we roll back the application to the previous version, i.e. 2, migrations will be rolled back to the state that was before feature 1, i.e. migration for feature 2 will also be rolled back. Which is most likely to break feature 2. The
question is how to deal with such situations?

Answer 1

Thus, the features were rolled out in the order - 2.1, and the migrations are sorted by timestamps, i.e. migrations will still be 1.2.

Don't migrations go by the date the db actually changed?
Well, it would be logical to use Milestones for this and plan for such things.

Answer 2

The correct approach is to avoid base rollbacks, the base should only go forward and always be backwards compatible (with some exceptions). In large projects, no one rolls back the database, but sometimes they make new migrations that do not vitiate the old ones. It's like a revert commit in git.