Skip to content


Subversion checkout URL

You can clone with
Download ZIP


not allowing QueryCache Rack to fail on database exception (#2142) #2227

wants to merge 1 commit into from

4 participants


I've been testing this (see sample app: and I actually think this is a bigger issue than raised in #2142. The query cache is triggered so early in the rack stack that if something goes wrong with the database (such as a misconfiguration or it goes down) it becomes a bit tricky to capture that error... you definitely can't do it from the controller level (it looks like hoptoad works as it monkey patches low enough to grab the error).

I think @pritchie has a valid point so here is my attempt to address it. if it fails in the QueryCache rack layer, let it continue through and if it fails somewhere else (most likely) then so be it; it will throw the same error but higher up on the stack where it can be handled by application-specific logic.

Please comment.



@skippy can you set a more descriptive message to the commit? :D


haha... yes


@skippy that works, but will the query cache now be off for the life of the Rails process?

Feels like we should be able to set the query cache flag even if the database isn't currently available.


I hate rescue Exception, can cause all kinds of unexpected behavior (rescued syntax errors etc...). How about rescuing StandardError instead?


@pritchie, addressing the 3 points in order:

  • the query cache will not be turned on IF the original connection fails; otherwise it will be there.

  • The querycache was baked into the connection, it seems, to just keep things clean, and now to pull it out seems messy. I made the change that I did to try and keep it small and focused rather than a (much) larger patch to decouple it completely from the connection. But I also think that is the right approach rather than having dependencies on the middleware (or some helper class). The other way to look at this is to not have ActiveRecord::Base.connection actually trigger a db call until used, but again, I think that is a thornier change outside of the scope

  • I looked at that, but the reason I kept it general is that the exceptions that are thrown are direct from the driver and are quite varied in type. I'm not sure you can make the expectation that they all stem from StandardError


I think it's reasonable to expect driver errors to inherit from StandardError. See:


Not turning on the query cache if the original connection feels like a bug. Perhaps a smaller bug than failing to start up at all, but a bug all the same.

Lazy load feels like the right option, but from looking at /connection_adapters/abstract/connection_pool.rb that's going to be adapter specific... given that some form of middleware or helper class might be cleaner.


hey @pritchie,
all your points sound valid, so I would say go for it and submit a patch with your thoughts in code.


What's happening to this PR guys??


@pritchie was correct in that it was not the cleanest; I was trying to minimize changes, but to do it 'properly' should probably convert some of the QueryCache class into using thread-local variables wrapped in class-scoped methods.


Can we close this PR. And you can submit the new one. What you say?


you bet, but I would look to @pritchie to submit what he thinks is appropriate; I picked this up during the rails bug squash and I don't see time coming up to rework this... sorry!

@skippy skippy closed this

No Probs @skippy . Thanks for your all hard work :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 23, 2011
  1. addressing rails #2142

    Adam Greene authored
This page is out of date. Refresh to see the latest.
2  activerecord/lib/active_record/query_cache.rb
@@ -61,6 +61,8 @@ def call(env)
status, headers, body =
[status, headers,, body)]
+ rescue Exception
11 activerecord/test/cases/query_cache_test.rb
@@ -31,6 +31,17 @@ def test_middleware_caches{})
+ def test_middleware_fails_but_passes_through
+ called = false
+ ActiveRecord::Base.connection.expects(:query_cache_enabled).raises(Exception)
+ mw = lambda { |env|
+ called = true
+ }
+ assert called, 'middleware should delegate even if connection failure occurs'
+ end
def test_cache_enabled_during_call
assert !ActiveRecord::Base.connection.query_cache_enabled, 'cache off'
Something went wrong with that request. Please try again.