The first test always fails with a MySQL connection error

[derekcroft]

The first test that runs tries to use an old MySQL connection and fails, then subsequent tests pass. This happens in every file, every time.

Loaded suite testr-worker[6] test/unit/subscription_test
Started
E........

1) Error:
test: A simple test should pass. (SubscriptionTest): 
ActiveRecord::StatementInvalid: Mysql2::Error: MySQL server has gone away: SAVEPOINT active_record_2
   config/initializers/mysql2_reconnect.rb:22:in `execute'
   test/unit/subscription_test.rb:81:in `block (2 levels) in <class:SubscriptionTest>'

[sunaku]

Interesting. If we turn off the parallelism (set TestR::Config.max_forked_workers = 1 in your .testr.rb file) does the error still occur? Also, this stackoverflow thread might be relevant:

Basically the problem is caused by the max_allowed_packet variable being set to something smaller than the blog/text field size. The query can't be executed so the connection gets dropped.

[sunaku]

@derekcroft Any update on this?

[citrus]

I'm seeing something similar with postgres on rails 3.2 pre:

   PGError: connection not open
    :           SELECT tablename
              FROM pg_tables
              WHERE schemaname = ANY (current_schemas(false))
    STDERR:

This is happening for the first test of each test file...

[citrus]

I was able to get past this by adding the following to my .testr.rb

TestR::Config.before_fork_hooks << lambda do |worker_number, log_file, test_file, test_names|
  defined?(ActiveRecord::Base) && ActiveRecord::Base.connection.disconnect!
end

TestR::Config.after_fork_hooks << lambda do |worker_number, log_file, test_file, test_names|
  defined?(ActiveRecord::Base) && ActiveRecord::Base.establish_connection
end

Now I'm having trouble with duplicate fixture data :/

[sunaku]

Thanks for your report @citrus. Since this issue was originally reported, I have wondered if [re-establishing DB connections in forked workers](http://modrails.com/documentation/Users guide Apache.html#_example_1_memcached_connection_sharing_harmful) was necessary in TestR. Your report has cleared my doubt. 🎁

Regarding duplicate fixture data, perhaps we need to make Rails apply fixtures once in the test_helper so that they are inherited into forked workers.

Also, if we turn off the parallelism (set TestR::Config.max_forked_workers = 1 in your .testr.rb file) does the issue still occur?

[sunaku]

@citrus I confirmed that your workaround solves the problem for Mysql completely. /cc @derekcroft

[sunaku]

@citrus I also confirmed that your workaround solves the problem completely for Postgresql.

[citrus]

Awesome, glad I could help!

As far as the fixtures go, I ended up using database_cleaner in my ActiveSupport::TestCase's teardown method to wipe the db after each test... Had some oddities but worked ok for the most part. Loading fixtures once per fork would make sense however and would alleviate the need for another dependency.

In the mean time I'll try turning off parallelism and will report my findings.

Cheers!

-Spencer

[citrus]

Thanks for adding my patch @sunaku!

I fixed my fixture problems by forcing my ActiveSupport::TestCase to use transactional fixtures with database cleaner making my test_helper.rb look something like this:

ENV["RAILS_ENV"] = "test"

require File.expand_path("../../config/environment", __FILE__)
require "rails/test_help"
require "database_cleaner"

DatabaseCleaner.strategy = :transaction

class ActiveSupport::TestCase

  self.use_transactional_fixtures = true

  def teardown
    DatabaseCleaner.clean
  end

end

Let me know if that works for you too...

-Spencer

[citrus]

Ahhh shit.. I'm still having issues with fixtures.. somewhat randomly too :/

Basically when I load testr and keep running all tests with r, I eventually get a PG deadlock error:

 test: WhateverController should get index.                              ERROR
        PGError: ERROR:  deadlock detected
        DETAIL:  Process 5211 waits for AccessExclusiveLock on relation 200824 of database 200811; blocked by process 5212.
        Process 5212 waits for AccessShareLock on relation 200814 of database 200811; blocked by process 5211.
        HINT:  See server log for query details.

I'm guessing this has something to do with using DB transactions..

[sunaku]

I don't understand why DatabaseCleaner is needed when you're using transactional fixtures: any changes you make to the DB in your test will be rolled back at exit anyway.

[sunaku]

@citrus any update on this? I didn't understand why DatabaseCleaner is needed in your example since you already have transactional fixtures enabled.

[citrus]

Sorry for the delay @sunaku.. I've been trying to create a demo app that replicates the issue...

Let's close this issue for now and I'll open a new one if I can get consistently failing results.

[sunaku]

Sounds good. Thanks @citrus.

[kurko]

Actually, I'm getting this error in an app that's not using tork. I'm using PostgreSQL, though.