Ash has a pretty cool feature that will auto generate migrations for changes in the resources. This is done by having “snapshot” json files that Ash looks to find what changed from the last migration.

This works great when you are working alone in a project, but we started seeing some problems with it when we have multiple developers working in different features that will generate migrations in their branchs.

Here is an example on how to trigger the issue:

1. Dev 1 creates a new branch based on master which has a migration snapshot (json file) A;
2. Dev 2 also creates a new branch based on master with the same migration snapshot A;
3. Dev 1 adds a new change to the resource and Generates a new migrations which will generate snapshot B;
4. Dev 2 also adds a new change to the same resource and generates a new migration which will generate snapshot C;
5. Note that both snapshot B and snapshot C are based in snapshot A;
6. Dev 1 merges to master its branch;
7. Dev 2 merges to master its branch;
8. Now, if we run ash_postgres.generate_migrations, ash will create a new migration file doing the same change snapshot B did even though that migration was already created and applied to the DB.

The reason for that is because since snapshot C was created based on snapshot A instead of B, then it doesn’t knows about snapshot B and it doesn’t knows about its changes, so it will assume that they don’t exists and will create a new migration with these changes again.

The way that we are working around this issue here in my project is that when we are ready to merge a branch that has migration changes to master, we delete all the migrations we did, we update the branch to the latest master commit, and recreate the migrations and do the merge.

That way, as long as no one else is merging to master at the same time, this will guarantee that we will have correct migration being created.

So, the question is, is there a better way to handle that or some other command/workaround for it?