> Do you remember why you reset the migration status in-between batches?

It is reset because self._view_can_be_migrated uses the migration status to check if dependencies are migrated to decide if a view can be migrated or not. The reset introduces a new crawl (not a fetch from the inventory database) when the migration status is requested through the index.

@FastLee and @nfx : As code improvement // tech debt, I suggest to always crawl the migration status and update the migration status in the inventory database. (Not in this PR, but as separate work to be planned accordingly.)

When requesting the migration status in the code (only used in the table_migrate), we always want the up-to-date status. Now, we get the up-to-date version by resetting the migration status sometimes, creating implicit dependencies between where the migration status is reset and retrieved through index - spanning across methods.

It took me quite some time to figure out how/why the migration status was not refreshed in certain cases and why it was in others, and why my first changes let other test fail. IMO the code becomes clearer by removing the implicit dependency.

Originally posted by @JCZuurmond in #1599 (comment)