Separately, this redis_config could definitely be split up into multiple files since there are a few separate jobs being done by the file. The global namespace method/constants are sort of odd and could be packaged into a class or added to existing class. The sidekiq config stuff could probably just be inlined in the existing sidekiq config. The test_env_number config could probably be its own initializer, or in the test env file, etc...

it would be useful to get a better specified version of "when we ran this on m.s here's what broke

It broke on my own instance. I got those errors in the web/sidekiq processes when the cache was accessed:

RedisCacheStore: write_entry failed, returned false: Redis::CommandError: NOAUTH Authentication required.

I am using a Redis password, I assume this would not reproduce if you use the default host/port and no password.

I am using a Redis password, I assume this would not reproduce if you use the default host/port and no password.

Cool ... so something like "when there is a REDIS_PASSWORD value set via a .env file, that value is preserved and run in the app's redis config?" is more or less the condition to verify here?

Yes, I think that would have caught the issue

Little mini-test along those lines. I added a REDIS_PASSWORD=test line to development env .env files...

Running in current main, but commenting out the dotenv load line, I see a) only one load (from gem, as expected), and b) output like this in console:

irb(main):002> Rails.configuration.cache_store
=> 
[:redis_cache_store,
 {:driver=>:hiredis, :url=>"redis://localhost:6379/0", :expires_in=>10 minutes, :namespace=>"cache:7.1", :connect_timeout=>5, :pool=>{:size=>5, :timeout=>5.0}}]

Note how that test value has NOT made its way into the config string.

Running on this branch, I see the same single load output from the gem doing the load, and output like:

irb(main):001> Rails.configuration.cache_store
=> 
[:redis_cache_store,
 {:driver=>:hiredis, :url=>"redis://:test@localhost:6379/0", :expires_in=>10 minutes, :namespace=>"cache:7.1", :connect_timeout=>5, :pool=>{:size=>5, :timeout=>5.0}}]

Note how test is now present.

So ... I think for the narrow goal of fixing the double load call while not breaking the redis config load, this probably works. I could see an argument for taking as-is, or for doing more cleanup work around the redis config loading first to make this issue not relevant.