This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Thank you for your contributions.

If users had set the wrong option for an app in production env, the app would raise an exception and not start after upgrading Rails.
I thought it would be safer to output a warning instead of raising an exception.

This reflects other subframeworks behavior, for example

Raising is safer, imo, especially in production, because warning 99% would be unnoticed in logs.

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Thank you for your contributions.

This is still valid.

This seems to have broken some Active Job config with eager-loading enabled (queue_name_prefix specifically). Going to revert for now.

Reproduction steps:

1. Generate a new Rails app based on master.

2. Add a job that uses queue_as:

   # app/jobs/test_job.rb
   class TestJob < ApplicationJob
     queue_as :baz
   end

3. Set config.eager_loading and config.cache_classes to true in config/environments/development.rb.

4. Set config.active_job.queue_name_prefix in development:

   # config/environments/development.rb
   config.active_job.queue_name_prefix = "foo_bar"

5. spring stop && rails runner "puts TestJob.queue_name"

Expected output: foo_bar_baz. Actual output: baz.

This is a symptom that Active Job is being loaded earlier than config/environments/development.rb.

Yeah, that’s the case as far as I could tell. Surprising, but I guess nothing besides AJ queue_as relies on config being set at load time.

Er, maybe not. I was only looking at ActiveJob::Base.queue_name_prefix in my testing.