Description
Last week, our provisioned Postgres instance was dropped for our production app. Heroku reported it as a hardware failure on their end, and for ~10 minutes our database associated to SolidCache and SolidQueue was unreachable.
We had a cache check in a before_action in our application controller, which effectively short-circuited every request made to our application in that 10 minutes.
The exception happened in this file: app/models/solid_cache/entry.rb#44 and this was the exception:
NoMethodError: undefined method `select_all' for nil (NoMethodError)
results.merge!(connection.select_all(query, "SolidCache::Entry Load").cast_values(attribute_types).to_h)
As a result of this, I went looking for a reasonable fallback behavior, I figured if the db connection failed out from under my app instance, I should be able to consider it a cache-miss and fallback to the block. I could find no such setting in the ReadMe, and while it is definitely an edge case, this stuff does happen in production apps. It seems to me that SolidCache could be more resilient in this scenario and allow me to determine a fallback behavior of exception vs. cache-miss. I understand a default of cache-miss can take down a system potentially, but in our case, I would have preferred slower response times over a 500 error code.
I don't mind taking a stab at a PR if I have time, but I wondered if there was any consensus around having this as some kind of top-level configuration option as an opt-in feature.