Could you maybe give an example of some such invalid records this tool would handle?
Ideally, if we know some objects may be invalid and can reasonably fix them, that should be done in a migration without requiring an additional step from the user.
We’ve had many such cases in the past. For example, when uniqueness for some model wasn’t enforced in the DB and we ended up with duplicate records due to race conditions. In those cases we either deleted all but one of the records (example), or renamed all but one (example) before adding a db constraint to prevent recurrence. In some rare cases where we couldn’t figure out the correct resolution we error out in the migration (example), which isn’t ideal as it leaves the user with a half-migrated db they need to manually clean up.
For more complex checks that may require user action to resolve, we actually already have a tool that does exactly that - foreman_maintain. It has checks that can be run both pre- and post- upgrade or against a running system, and verify there are no invalid records of a certain type in the db (example).
Unfortunately, it is currently not yet supported on Debian and is rather more Satellite-oriented.
Rather than creating yet another tool and another upgrade step, I would much rather we invest in improving the existing tool, making it support all of the Foreman-supported platforms and scenarios, and adding more checks to it.