Teach ActiveJob to set configs on itself

[sambostock]

Summary

Previously configs of the form config.active_job.X were only forwarded to ActiveJob::Base. This teaches Active Job to set them on ActiveJob directly instead, if the setter exists.

Other Information

This is a follow up to #45618, which introduces the first config set on ActiveJob directly. @adrianna-chang-shopify pointed out that despite having set the config

# config/application.rb
config.active_job.use_big_decimal_serializer = true

the config was still set to the default value after the application was booted:

Rails.application.config.active_job.use_big_decimal_serializer # => true
ActiveJob.use_big_decimal_serializer                           # => false

In #45618, I had considered if it was more appropriate to set the config on ActiveJob::Base. While that might have allowed individual job classes to opt or out of the serializer (which is of questionable value), it would have required a change to the Arguments.serialize API to inject the job class. I assumed that the config would be automatically forwarded, without realizing that each framework is responsible for setting their config independently (perhaps an opportunity for helper extraction).

[skipkayhil]

Probably worth testing in railties/test/application/configuration_test.rb like

rails/railties/test/application/configuration_test.rb

Line 2645 in b01027f

test "custom serializers should be able to set via config.active_job.custom_serializers in an initializer" do

[sambostock]

Ahh, thank you @skipkayhil. I've added tests for the default value, and overriding it.

[sambostock]

This took a long time to figure out, as the assertion would just fail without it. It was particularly hard to test because the tests run in parallel with their output interleaved, and this suite would crash due to running out of file descriptors... (See #45667 😅)

It feels kind of weird that we have to do this. Nothing in the implementation BigDecimalSerializer, its use in Assertions, or let alone the configuration code references ActiveJob::Base, so it's weird that we have to reference it to get this to work. Is there a better way to do this, or is this acceptable?

I wonder if maybe I should have just set the config on ActiveJob::Base instead? That just felt like it attached it to a job, which Arguments isn't. 🤔

[casperisfine]

It probably shouldn't be set on on_load, Active Record does it on after_initialize, might as well be consistent:

rails/activerecord/lib/active_record/railtie.rb

Lines 226 to 238 in ab325a9

	config.after_initialize do
	configs.each do |k, v|
	next if k == :encryption
	setter = "#{k}="
	if ActiveRecord.respond_to?(setter)
	ActiveRecord.send(setter, v)
	end
	end
	end
	ActiveSupport.on_load(:active_record) do
	# Configs used in other initializers
	configs = configs.except(

[sambostock]

Okay, I've mirrored the approach, including the "double copying" for consistency. ActiveRecord does it for backwards compatibility though, which we don't technically need to support here (since use_big_decimal_serializer is the first config on ActiveJob directly).

[rafaelfranca]

Should not this be app.config or just config? And why do it twice?

[sambostock]

@byroot recommended copying the approach from ActiveRecord::Railtie for consistency (#45664 (comment)), which is why we're doing it twice. I'm glad to change this to whatever is determined to be the correct way to do it.

However, I do see that I misread, and ActiveRecord::Railtie is calling after_initialize on config, not configs, so I'll fix that. It is clearer here with the (existing) name options, which stands out as different.

[byroot]

@sambostock can you also add a fix for the issue @rafaelfranca noticed in #45618 (comment) ? It can go in the same commit as this.

[sambostock]

@byroot done! I've also added the contributor documentation comment, as discussed. Hopefully I got it all correct.

[byroot]

Thanks Sam. I'll try to review this later today, in the meantime can you squash your commits? Otherwise I can't merge.

[byroot]

Suggested change

	# 4. Add a commented out section in the new_framework_defaults file, setting the new value.
	# 5. Update the guide on configuration.
	# 4. Add a commented out section in the new_framework_defaults template, setting the new value.
	# 5. Update the guide in `configuring.md`

[sambostock]

Updated. I also realized I omitted the step of actually implementing the change, and its corresponding removal step, so I added that too.

Commits squashed too.