Rubocop: Detect mixed use of concurrent/standard migration helpers

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Migrations should not mix concurrent and standard migration helpers. Or to put it differently: We have to be diligent about migrations that only run with transactions disabled (e.g. concurrent helpers). Mixing in standard migration helpers (like create_table) becomes a problem if the migration fails: Without transactions enabled, create_table already committed but the migration failed. Once we retry, the table already exists - which makes the migration failure unrecoverable.

Can we establish a rubocop to enforce this?

• @DouweM started a discussion:

  Is this something that could be automated (rubocop)?