Our work to manage upgrades in multi-PuppetDB environments broke our migration model because it only check the most recent migration number and assumes we have all the others. This could result in a PuppetDB misidentifying a Postgres as having "valid schema" when in reality an upgrade is required.
Our migration code properly distinguishes between "pending" migrations that it recognizes and has yet to apply, and unrecognized migrations, migrations that have been applied that it doesn't know about. But other parts of the migration orchestration code only look at the highest numbered migration. So in a world where we apply a migration to an old branch (6.x) you might have a set of migrations like
... 78 79 __ 81
and this version would not notice that the schema was out of sync when the db is upgraded to the new branch (main) with the migrations
... 78 79 80 81
It's important to keep in mind that we have done migration "roll-ups" as well. This means that migrations lower than the lowest number in our migration map should not be treated as "unrecognized" migrations.
Our work to manage upgrades in multi-PuppetDB environments broke our migration model because it only check the most recent migration number and assumes we have all the others. This could result in a PuppetDB misidentifying a Postgres as having "valid schema" when in reality an upgrade is required.