Autoloading in Rails initializer

[oskarpearson]

Is your feature request related to a problem? Please describe.

In Rails 7 autoloading is disabled when an application boots. So things in the config/initalizers folder don't support autoloading.

However, the Datadog dd-trace-rb gem Rails integration takes a exception_controller parameter which needs to point at the class. Something like this:

Datadog.configure do |c|
  c.tracing.instrument :rails, exception_controller: ErrorsController

To use this, we need to jump through some hoops - like wrapping the whole of the datadog initialisation in Rails.application.reloader.to_prepare do (which I expect won't work anyway?), or the config.autoload_once_paths Rails feature. Using the latter (as I read it) means we can't autoload code when ErrorsController loads.

Describe the goal of the feature

I'd like to be able to pass a Symbol or string as the exception_controller parameter, rather than the actual class.

• In sidekiq they refer to passing a symbol Rails 6 + DEPRECATION WARNING: Initialization autoloaded the constants... sidekiq/sidekiq#4192 (comment)
• In ActiveAdmin they pass a string https://activeadmin.info/13-authorization-adapter.html

So the Datadog config would change to something like c.tracing.instrument :rails, exception_controller: :ErrorsController or potentially c.tracing.instrument :rails, exception_controller: "ErrorsController"

Describe alternatives you've considered

None

Additional context

https://github.com/DataDog/dd-trace-rb/blob/cb6f3a4ed44d41719570ed30ae8da19dd1f73c51/lib/datadog/tracing/contrib/action_pack/action_controller/instrumentation.rb would need to try and use constantize of the supplied parameter (currently it just returns false if it's not a class or module)

How does ddtrace help you?

N/A

[TonyCTHsu]

👋 @oskarpearson , Thanks for sharing this. I think it make sense exception_controller should be a string instead of a constant. I guess the changes will not be difficult with constantize.

However, I would like learn more about the trouble of our current implementation with Rails 7 autoloading.

Is it broken in some ways we overlooked? or it is working as expected but having some kind of bad developer experience?

Could you provide me a bit more description about the current behaviour and what is causing trouble? So that I can search through the project to see with there are issues with similar patterns.

[jens]

For us the application fails to boot with a NameError uninitialized constant ErrorsController.
So using the exception_controller with Rails 7 doesn't work.

[oskarpearson]

@TonyCTHsu Thanks for the followup here

The breakage is that using the suggested c.tracing.instrument :rails, exception_controller: ErrorsController syntax

• Worked ok in Rails 5.
• In Rails 6, we would get the warning DEPRECATION WARNING: Initialization autoloaded the constant ErrorsController.
• In Rails 7 it won't work at all, and the application will fail to boot

For more detail, see
https://rubyonrails.org/2021/9/3/autoloading-in-rails-7-get-ready

You can replicate this easily - build a new Rails 7 application, add datadog to it, add an ErrorsController class, and then add a config as follows:

Datadog.configure do |c|
  c.tracing.instrument :rails, exception_controller: ErrorsController
end

On Rails 7 it will refuse to boot, and you will receive the error:

uninitialized constant ErrorsController (NameError)

  c.tracing.instrument :rails, exception_controller: ErrorsController
                                                     ^^^^^^^^^^^^^^^^

[marcotc]

I suggest allowing a fully qualified class name String to be provided in the exception_controller: option.
The symbol approach won't work so well with namespaces.
We would still support passing the class directly for backwards compatibility.

[delner]

What's the next step here @TonyCTHsu and @marcotc ?