Turns out we need not only to load the Job constants later, but also
not to do the same work twice – otherwise we'll get a
> ApiEntreprise::Job constant is already defined
when attempting to re-define the constant.
Fix a warning when running tests:
> DEPRECATION WARNING: Initialization autoloaded the constant DynamicSmtpSettingsInterceptor.
>
> Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
>
> Reloading does not reboot the application, and therefore code executed during
> initialization does not run again. So, if you reload DynamicSmtpSettingsInterceptor, for example,
> the expected changes won't be reflected in that stale Class object.
>
> This autoloaded constant has been unloaded.
>
> Please, check the "Autoloading and Reloading Constants" guide for solutions.
However if we fix as recommanded, the interceptor will get added
each time the classes are reloaded. And as the actual class instance
changed after the reloading, they won't be de-duplicated – *and*
there's no way to remove the old interceptor without having a reference
to the (now-deleted) class.
Instead we load the interceptor once, and add a message about the class
not being auto-reloaded.
This removes spam in the debug console when running locally.
Removed messages look like a swarm of:
> [Tracing] Discarding <rails.request> transaction </assets/marianne.png> because it's not included in the random sample (sampling rate = 0.001)
Fixes zeitwerk complaining that the compatibility aliases loaded in an
initializer will never be reloaded.
In our case it doesn't matter that much, but it will reduce the console
spam.
When running several individual tests in succession using Spring,
we get an error message:
> zeitwerk error: reloading is disabled because config.cache_classes is true
Caching classes during tests used to be recommended – but Rails 6
now recommands to reload them:
- Spring takes care of the caching for us,
- It makes zeitwerk happy.
See discussion in 65344f254c
A potential downside used to be that when running system tests using
Capybara, each web request would reload the classes, which invalidated
the model objects of the test case. But it seems to be fixed now.
