Madmin breaks application boot when a migration adds a field and a madmin attribute is added before running the migration.
jean-francois-labbe opened this issue · comments
When adding a new field to a model and declaring those fields as madmin resource attributes.
Pushing this new commit to production fails to boot.
It seems that madmin is trying to access the field, but the migration has not been executed.
The migration cannot be executed as the application wont boot.
2022-01-21 17:16:45.181950167 +0000 UTC [web-1] /app/vendor/bundle/ruby/3.0.0/gems/madmin-1.2.6/lib/madmin/resource.rb:172:in `fetch': key not found: nil (KeyError)
2022-01-21 17:16:45.181951783 +0000 UTC [web-1] from /app/vendor/bundle/ruby/3.0.0/gems/madmin-1.2.6/lib/madmin/resource.rb:172:in `field_for_type'
2022-01-21 17:16:45.181952400 +0000 UTC [web-1] from /app/vendor/bundle/ruby/3.0.0/gems/madmin-1.2.6/lib/madmin/resource.rb:35:in `attribute'
2022-01-21 17:16:45.181952993 +0000 UTC [web-1] from /app/app/madmin/resources/questionnaire_resource.rb:11:in `<class:QuestionnaireResource>'
2022-01-21 17:16:45.181953456 +0000 UTC [web-1] from /app/app/madmin/resources/questionnaire_resource.rb:2:in `<main>'
I have the same problem here (sort of): when a review app is started automatically by Scalingo for the first time, the database has not been initialized yet, because the app starts before the init scripts is run for the first time.
Which results in this error:
2022-09-02 06:19:34.543722746 +0000 UTC [web-1] from bin/rails:4:in `<main>'
2022-09-02 06:19:34.543734501 +0000 UTC [web-1] /app/vendor/bundle/ruby/3.1.0/gems/activerecord-7.0.3.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:19:in `exec': ERROR: relation "events" does not exist (PG::UndefinedTable)
2022-09-02 06:19:34.543734842 +0000 UTC [web-1] LINE 9: WHERE a.attrelid = '"events"'::regclass
2022-09-02 06:19:34.543735145 +0000 UTC [web-1] ^
Did you find a way to avoid madmin to access the ressources at application start up?
For those who still face this issue, it's possible to avoid the db calls with an explicit type definition in ModelResource file :
class ModeleResource < Madmin::Resource
...
attribute :content, :rich_text
attribute :position, :integer
...
It's more a workaround than a solution but it allowed me to fix my deploy.