ReversibleMigration: remove_reference is not reversible.

[TonyArra]

Behavior was introduced in: #592

Expected behavior

No warning for usage of remove_reference or remove_belongs_to in a migration.

As far as I can tell, remove_reference is reversible. Its inverse is available in ActiveRecord::Migration::CommandRecorder, and I'm able to rollback with it.

Actual behavior

Receive the following warning:

db/migrate/20210826075926_x:5:5: C: Rails/ReversibleMigration: remove_reference is not reversible.

Steps to reproduce the problem

Run rubocop on a migration that uses remove_reference or remove_belongs_to

RuboCop version

❯ rubocop -V
1.24.0 (using Parser 3.0.3.2, rubocop-ast 1.15.1, running on ruby 2.7.4 x86_64-darwin20)
  - rubocop-performance 1.12.0
  - rubocop-rails 2.13.0
  - rubocop-rake 0.6.0
  - rubocop-rspec 2.6.0

[pirj]

Isn't it only reversible if it lists all the qualifiers as the add_reference has, like index: { unique: true, name: 'my_index' }, foreign_key: { to_table: :firms }? If one skips any of that in remove_reference, it would rollback to a slightly different state than it was before forward-running the migration. Unique index and fk table seem most problematic, and may break existing specs. They would have to create and migrate the DB from scrath on their local machine, or rollback until the migration with add_reference.
Is there a way to reliably tell if add_reference options were later used with remove_reference? It's hard with static analysis, you would have to read other migration files. I am uncertain if it's also possible in runtime, as CommandRecorder only dry runs one migration, and has no records about the one with the initial add_reference.

I'm in doubt about adding remove_reference to the allow-list.
On the one hand, we are not excessively cautious, even though we'll miss those incomplete remove_reference options.
On the other - if we be excessively strict, and suggest users to mark those statements with # rubocop:disable Rais/ReversibleMigration.
How do you suggest approaching this?

[TonyArra]

@pirj isn't the same thing true of all the other reversible migration statements?

For example, if I add a column with additional options, like default:

    add_column :comments, :position, :integer, default: 0

and then later remove that column without specifying those same options

    remove_column :comments, :position, :integer

Then it won't properly rollback to its previous state. It will be missing the default.

[pirj]

Fair enough 👍
Would you like to send a PR?

[TonyArra]

@pirj sure, I can do it a few hours from now if you don't mind