ActiveRecord::ConnectionNotEstablished when using async mode

[sj26]

I have a fairly standard new-ish rails app setup with puma, and added the following:

# config/initializers/development.rb
Rails.application.configure do
  # ...
  config.active_job.queue_adapter = GoodJob::Adapter.new(execution_mode: :async)
  # ...
end

Then ran:

DISABLE_SPRING=1 bin/rails server

But got:

❯ DISABLE_SPRING=1 bin/rails server
=> Booting Puma
=> Rails 6.0.3.2 application starting in development 
=> Run `rails server --help` for more startup options
/usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/good_job-1.2.1/lib/good_job/adapter.rb:11: warning: Passing the keyword argument as the last hash parameter is deprecated
/usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/good_job-1.2.1/lib/good_job/configuration.rb:5: warning: The called method `initialize' is defined here
Exiting
Traceback (most recent call last):
...
	 7: from /Users/sj26/Projects/TheSizzle/config/environments/development.rb:34:in `block in <main>'
	 6: from /Users/sj26/Projects/TheSizzle/config/environments/development.rb:34:in `new'
	 5: from /usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/good_job-1.2.1/lib/good_job/adapter.rb:23:in `initialize'
	 4: from /usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/good_job-1.2.1/lib/good_job/scheduler.rb:42:in `from_configuration'
	 3: from /usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/good_job-1.2.1/lib/good_job/scheduler.rb:42:in `map'
	 2: from /usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/good_job-1.2.1/lib/good_job/scheduler.rb:44:in `block in from_configuration'
	 1: from /usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/good_job-1.2.1/lib/good_job/configuration.rb:37:in `max_threads'
/usr/local/rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/activerecord-6.0.3.2/lib/active_record/connection_handling.rb:217:in `connection_pool': ActiveRecord::ConnectionNotEstablished (ActiveRecord::ConnectionNotEstablished)

It looks like accessing ActiveRecord::Base.connection_pool.size at this point of rails initialization is too early.

[sj26]

Perhaps good_job needs a railtie?

[bensheldon]

I went down a rabbit-hole of allowing the Scheduler/Notifier to defer some of this setup and starting of threadpools until a later time via a Railtie and it got somewhat gnarlier than I was happy with. I may continue down that path in the future.

I wonder though, more simply, if it's possible to just hardcode the max threads rather than ask the database adapter, or to ask for the database configuration in a lighter way.

[bensheldon]

@sj26 I removed the reference to ActiveRecord::Base.connection_pool.size in #137.

[obie]

@sj26 I removed the reference to ActiveRecord::Base.connection_pool.size in #137.

This is still not released right?

[bensheldon]

👍 It was released in v1.2.6.

[bensheldon]

I believe that this is fully addressed with the changes in #199 that use Rails configuration to defer the creation of objects that touch ActiveRecord until Rails is fully bootstrapped.