Checking in tests/specs that READs actually go to the replica

[serggiu]

First of all, this is a great gem, thank you for sharing it with us!

I've added it in an app and it's working great, though I'm trying to validate with some specs that READs actually go to the read replica, and it doesn't seem to make this switch automatically in a test environment.

Here's a simple spec, please let me know if specific configuration is needed to make the gem work in a test environment:

  it "fetches from the read replica" do
      expect { User.count }.to exactly_query_databases({ primary_replica: :reading })
  end

and I get back { primary: :writing }, not { primary_replica: :reading }

If I manually switch to the read replica, then I get back what I'm expecting:

it "fetches from the read replica" do
    ActiveRecord::Base.connected_to(role: :reading) do
      expect { User.count }.to exactly_query_databases({ primary_replica: :reading })
    end
  end

I must be missing something though it's not obvious to me.

Thank you

[mateuscruz]

Hello @serggiu.

I moved this to the discussions tab as it's more of a question than a bug.

The most likely reason you're seeing this behaviour in your test case is you have transactional fixtures in your test config or, if you're using the database_cleaner gem, your test database is being cleaned with the :transaction strategy.

Anything inside a transaction will always go to the primary (as it makes no sense to open a transaction in a replica).

So your test case should work if you don't wrap your test cases in transactions. You could use truncation instead.

Although I'm not sure what you're trying to achieve with that test case. It's not usually advised to write tests for third party code, we usually write tests for code we write. We have thorough, comprehensive coverage on the behaviour you're trying to test.

The latest gem version has about 97% overall test coverage.

I hope that helps clarify things.

[serggiu]

Hey @mateuscruz, thank you for your response.

The only thing I'm trying to achieve is a simple test that shows that a READ goes to the read replica, nothing fancy.

I know you guys are doing a fantastic job and have full coverage on all logic, though I wanted to have a simple validation test in our test suite just in case, it never hurts being extra careful.

With transactional fixtures disabled and DatabaseCleaner.strategy = :truncation I still see the queries going to the primary, not to the read replica. I'll figure it out.

Thank you for your time and keep up the good work!

[mateuscruz]

Please let us know if you're able to make your test pass.

[serggiu]

I could not make it work yet, and looking at the rails log I'm sure there's no transaction active, so it's all happening outside of a transaction. I'll debug a bit more and will share what I can find, or maybe even try all this in a new, small and clean app to see if it works in specs.

[mateuscruz]

What value for config.proxy_delay are you using in your test case? Is it sufficiently low to ensure that other queries outside your test case might not be interfering with it?

Also, try adding this before hook to clean up the proxy context. The context might be dirty from other test cases.

config.before do
  proxy_config = ActiveRecordProxyAdapters.config
  ActiveRecordProxyAdapters::Contextualizer.current_context = proxy_config.context_store.new({})
end

[serggiu]

This looks promising.

I'm using the default for config.proxy_delay = 2.seconds

The way I'm checking for the used db connection is by subscribing to the sql.active_record notifications.

I have added the before hook as you suggested and something did change, but now I'm getting two notifications for a simple User.count, as if it's first connecting to the :writing role, then connecting to the :reading role.

If I wrap my query like this ActiveRecord::Base.connected_to(role: :reading) { User.count }, I get three notifications, and all of them for role reading.

Any idea why is it connecting first to the :writing role which is for the primary db and not. connecting directly to the :reading, primary_replica database?

[serggiu]

@mateuscruz thank you for your patience, I got the tests working eventually.

The initial sql.active_record notifications being triggered were related to some setup queries that are run at the beginning of the tests suite, and those were run on the primary.
I've updated my rspec matcher to skip those and now I'm only checking for the relevant sql.active_record notifications and indeed my User.count goes to the replica! 🎉 🎉

[serggiu]

@mateuscruz I forgot to ask something that may be important: what happens if the read replica is not accessible, does the proxy silently fallback to the primary db or does not show connection errors?
My guess is it should show connection errors instead of masking them but I wanted to ask before I go look for this through the code.

One other thing that confuses me a bit (while testing our update on our staging): I check the database configuration in the rails console like this:

irb(main):001> ActiveRecord::Base.connection_db_config
=> 
...
adapter: "postgresql"
...

I would have expected the adapter to be postgresql_proxy but it's not. Does this look ok to you?

Thank you!

[mateuscruz]

forgot to ask something that may be important: what happens if the read replica is not accessible, does the proxy silently fallback to the primary db or does not show connection errors?
My guess is it should show connection errors instead of masking them but I wanted to ask before I go look for this through the code.

That question is unrelated to your main one so it's better if you create a new discussion as other people might have the same question.

I would have expected the adapter to be postgresql_proxy but it's not. Does this look ok to you?

Hard to say with the very little information you provided. I don't know what your database.yml looks like, or what your models look like. If you can provide those, I might be able to help.