database is locked

[ali-bugdayci]

Using: parallel_tests 0.16.6.

Getting the sqlite busy exception when running tests through parallel_tests. I even tried pool 1 inside database.yml, on the test database so that each spec waits for the next one.

"parallel_rspec spec -n 1" works fine, when I give "-n 2" it fails.

Am I missing something?

parallel_rspec spec
   ....(other 16 test passing)
   1) Borough start visiting list of boroughs: shows
     Failure/Error: let!(:borough) { create(:borough) }
     ActiveRecord::StatementInvalid:
       SQLite3::BusyException: database is locked: INSERT INTO "cities" ("created_at", "name", "updated_at") VALUES (?, ?, ?)

database.yml:

test:
  adapter: sqlite3
  database: db/test.sqlite3<%= ENV['TEST_ENV_NUMBER'] %>
  pool: 1
  timeout: 5000

[ronwsmith]

Trying moving the test env earlier: database: db/test<%= ENV['TEST_ENV_NUMBER'] %>.sqlite3

It shouldn't make a difference, but I personally structure it a little differently, so it might be worth a try: database: <%= "db/test#{ENV['TEST_ENV_NUMBER']}".sqlite3 %>

[grosser]

thx for helping out @ronwsmith !

[ali-bugdayci]

Still getting the same error. If database.yml was erroneous, then I should take migration errors.

parallel_rspec spec -n 1 works but when multiple processes work it gives: SQLite3::BusyException:

database.yml
  database: db/test<%= ENV['TEST_ENV_NUMBER'] %>.sqlite3

~/code/f[master*]% ls -1  db/test* 
db/test2.sqlite3
db/test3.sqlite3
db/test4.sqlite3
db/test5.sqlite3
db/test6.sqlite3
db/test7.sqlite3
db/test8.sqlite3
db/test.sqlite3

[ali-bugdayci]

By the way, it magically runs fine with zeus.

zeus parallel_rspec spec
18 examples, 0 failures, 2 pendings

But since these issues are multi forked/threaded stuff, leading to race conditions, I suspect that it might not work in the future.

[ronwsmith]

I'm not familiar with SQLite3, but it sounds like something is hitting the main db before the threading begins. Researching that error and found that a common fix is to add timeout: 10000 to your database.yml for the env you're in. Does that help?

[botandrose]

It's almost certainly spring, holding on to the original db configuration. To confirm, remove spring from your Gemfile and binstubs. You can conditionally disable spring when TEST_ENV_NUMBER is present, but I'll leave that as an exercise to the reader.