these lines mention initialising Rails.cache so railties can make use of it, however, when used in tandem with rails credentials, because the env isn’t completely loaded at this point, this does not work well and Rails.cache is set to the default.
What you’re describing sounds like it could be a bug. Could you report it to the Rails issue tracker? It would be helpful to include a simple that app that demonstrates the issue.
Yeah, so, rails credentials seems to be unreliable in general within rails itself. We have so far found a couple of issues related to DB and now with cache, with little support for the DB issue at least. Hence, I wanted to understand the reasoning for this early initialisation of
Rails.cache, before attempting a fix.
That comment is your answer. If you’re wondering which Railties specifically use the cache and what values they’re putting into the cache and how they’re dealing with an incompletely initialized environment… I think look searching through the code is your best bet.
My perspective is that it’s reasonable to initialize the cache, but each individual component/Railtie/gem that uses the cache during initialization is responsible for what they put in it.
For example, if there is a particular value that needs to stay dynamic through initialization and configuration loading, it’s the component that shouldn’t be putting it into the cache until after initialization or should be actively managing cache invalidation; that’s a bug
I believe that removing the cache itself will be a nonstarter.