fix: Eager load when 'rake_eager_load = false'

[smudge]

By default, Rails wants to disable eager loading inside of rake commands, even if eager_load is set to true. This is done to speed up the boot time of rake tasks that don't need the entire application loaded.

The problem is that long-lived processes like delayed do want to eager load the application before spawning any threads or forks. (Especially if in a production environment where we want full load-order parity with the rails server processes!)

When a Rails app boots, it chooses whether to eager load based on its eager_load config and whether or not it was initiated by a rake command. If it did eager load, we don't want to eager load again, but if it was initiated by a rake command, it sets eager_load to false before the point at which delayed starts setting up its rake environment.

So we cannot rely on that config to know whether or not to eager load -- instead we must make an inference:

• Newer rails versions (~7.0+) have a config.rake_eager_load option, which tells us whether the app has already eager loaded in a rake context.
• If rake_eager_loading is not defined or false, we will then check cache_classes & explicitly eager load if true.

/no-platform

[aryakarnik1]

What does !Rails.application.config.cache_classes check for? My understanding is it skips eager loading in development (where cache_classes = false) since classes reload anyway. Is that correct?

[smudge]

Yeah -- if cache_classes == false, I use that as a signal to skip eager loading.

In newer rails versions, cache_classes is equivalent to !enable_reloading. So line 37 could be read as:

next if eager_loaded || Rails.application.config.enable_reloading

So if you've already enabled dynamic reloading, then we infer that you aren't in an environment where you care about deterministic load order in general.

[aryakarnik1]

makes sense, thanks!