I added a migration C that depends on migration A. Migration B also depends on migration A. Migration A is the initial schema that adds all the necessary tables, (including the sm_blocks table), and also has the instructions to drop the tables when purging the extension. Migration C modifies the sm_blocks table by adding a column and removing another, and also has revert_schema to undo the changes as it is recommended to do.

Everything works fine except when you decide to purge the extension. For whatever reason, migration A is reverted before migration C. So sm_blocks table is dropped before the changes introduced by migration C are reverted, resulting in a database error, which prevents the extension from being purged. At this point, the extension cannot be purged, and it cannot be re-enabled since the sm_blocks table no longer exists.

Doing further research on this shows that the migrations are loaded correctly (i.e.migration B runs, then C, and then A) when purging but the purge step for migration A drops the first table, sm_blocks, then it goes back and starts with migration B, then C again, and this time, because the sm_blocks table was previously deleted, we get an error.

I found that I can fix the issue by making migration C depend on migration B instead of A (which doesn't make sense) or by removing the revert_schema method from migration C but migration validation policy recommends providing instructions to revert any schema changes. Granted, you could also say let the extension author figure this out and use if conditions in the revert_schema method to avoid this issue, so we only revert if the table exists, but I think phpBB needs to handle these better.

I tried looking at the migrator and changing the order in which it reverts migrations but that seemed to complicated. The easiest option, I think, is to have db_tools verify that the table actually exists before trying to modify its columns, etc. I will provide a pull request for this shortly...