Failed with: Unable to find migration version to revert in the migrations directory.

[Yoric]

Diesel used to work nicely.
All of a sudden, after a git pull --rebase (I think),

$ diesel migration revert
Failed with: Unable to find migration version to revert in the migrations directory.

However,

$ diesel migration list
Migrations:
  [X] 00000000000000_diesel_initial_setup
  [X] 2021-03-25-160646_rooms_to_ignore
  [X] 2021-03-30-160520_keywords
  [X] 2021-04-09-121228_descriptions

Does anyone know what is going on and what I can do to fix it?

I'm running diesel_cli v1.4.1 on postgresql.

[weiznich]

This is expected behavior, thought the error message could be clearer here.
Diesel tracks which migrations are applied and which are not applied yet in a database table. This table does not contain the migration itself or the corresponding down migration. To revert a migration the corresponding migration is searched in your local migration folder based on the migration version (that's by default the timestamp in front of your migration name). If no migration with this version is found locally this error message is returned.

That all written: Improving this error message is definitively possible. If someone is interested in contributing here feel free to get in touch with me to get some more specific information about were to look for the corresponding code.

[Yoric]

Apparently, there is something that diesel cli does and that I do not understand.

As far as I understand, the sole state of diesel cli is __diesel_schema_migrations, which only contains the list of migrations it knows and whether they have been run. My understanding is that both diesel migration list and diesel migration revert look at this table to determine which migrations have been run/need to be reverted, right?

Are you telling me that in my case, one of the migrations was in __diesel_schema_migrations but not in my migrations/ directory? I don't think that this is what happened but I may be wrong.

If that's the case, yes, a better error message that mentions which migration is missing (or at least its version) would be really useful.

[weiznich]

Are you telling me that in my case, one of the migrations was in __diesel_schema_migrations but not in my migrations/ directory? I don't think that this is what happened but I may be wrong.

That's exactly your issue.

If that's the case, yes, a better error message that mentions which migration is missing (or at least its version) would be really useful.

We are happy to receive a contribution here. Otherwise this is possibly already fixed by #2657

[Yoric]

PR opened: #2723 .

It should help a bit.

[Mingun]

While design goals are understandable here, I think, that diesel CLI could handle this situation better:

• diesel migration list could check the filesystem and the database and output migrations from both lists merged. The migrations that is not in both lists should be marked. The output might looks like:

  $ diesel migration list
  Migrations (/path/to/the/migration/folder):
    [X] 00000000000000_diesel_initial_setup
    [X] 2021-03-25-160646_rooms_to_ignore (missed file)
    [X] 2021-03-30-160520_keywords (migration file is not tracked)
    [X] 2021-04-09-121228_descriptions
  
  error: your migrations are corrupted (the exact message could be better, suggesting the ways to resolve this case)
  

• diesel migration revert can have a --force/-f flag to explicitly ignore absence of missed files / DB entries and assume that nothing to do in that case
• Diesel can provide a new command diesel migration repair which will recreate internal DB state from existing files in migration directory, maybe asking if file should be applied/marked as applied/marked as unapplied/skipped and deleted

That's my 2 cents. It's all about quality of life issues which distinguish simply good software from excellent.

[weiznich]

I agree that this could be handled in a better way, but after all that would need someone that thinks that this is more important than other features and spend time to:

• bring up a complete design
• implement the changes
• adds tests + documentation for these changes.

There is unfortunately only that much time everyday, so I won't have the capacity for that. Feel free to contribute such changes.