testdouble/good-migrations

Migration not raising error

Closed this issue · 4 comments

I'm trying to implement good migrations in an existing rails app, but I can't figure out why isn't the gem raising errors.

I have created the following migration which should raise an error:

class BadMigration < ActiveRecord::Migration[6.1]
  def change
    User.all
  end
end

But when the migration is run, I get the following output, without any error or warning:

> DISABLE_SPRING=1 bundle exec rake db:migrate
== 20221201132109 BadMigration: migrating =====================================
== 20221201132109 BadMigration: migrated (0.0002s) ============================

I've setted config.autoloader = :zeitwerk in application.rb and config.eager_load = false in development.rb.
Currently using rails 6.1.4 and zeitwerk 2.6.6, any Ideia what could be going wrong?

Could you share a minimal repro repo?

I built this demo app for testing. I guess the problem is around some gem version, because it was working fine before I updated the Gemfile with my app's gems.

Sorry I only had 30 minutes to devote to this but I pulled down your demo app, saw that with all the versions locked as you had them the problem is reproducible.

I tried debugging the issue and AFAICT something was interacting with the zeitwerk autoloader configuration and the good_migration gem was never called back by the loader. However, if I removed all the version pins from the Gemfile and ran bundle update gist here of what it resolved to, the gem behaves correctly and raises the error.

Because there are so many gems involved and because some might be interacting with zeitwerk, I think fixing this or bisecting it is out of scope for us in maintaining this gem. If you manage to bisect to a direct cause that can be solved inside the gem, I'd appreciate it, but until then I'm going to close the issue. I hope you understand!

I understand, thanks a lot! After some debugging I managed to discover the gem causing the issue. The problem is caused by the AVO gem version, which needs to be 2.19+.

Also, for anyone that might get through this problem in the future, there is still some issue regarding the compatibility with avo gem, where no error is raised if there is an avo resource with the same name of the active record model called in the migration.
For example, if you call User.all in a migration, but have defined class UserResource < Avo::BaseResource, then no error will be raised. Couldn't find a way to fix this though.