I found that some of my tests had GenServers running (started in the test setup using start_supervised!/2), and the GenServer was outliving the test’s sandbox repo connection. I had to make sure I had an on_exit handler that stopped the GenServer from continuing to try to use the database before the rest of the test teardown could happen.

The usual cause of that message is code that’s still waiting for the result of a Repo call when the test process shuts down.

Just to chime in with we seem to have the exact same intermittent errors.

We discovered they were MUCH worse when running the Elixir process locally but the database in docker on M1 Macs. Working theory being that it’s because the network connection on docker for Mac is quite slow.

The error also happens a lot more along with lots of intermittent failures when running in Github CI which are fairly resource constrained instances.

So wondering if it’s something to do with running lots of DB intensive stuff with some form of resource bottleneck. E.g. on Github actions there’s only 2 cores available for DB and parallel tests combined.

Thanks for that info, @danturner. It turns out that all the tests exhibiting this behavior had one thing in common – they all started a GenServer (using start_supervised!) that was running a periodic query in the background. I added an on_exit handler to tell the GenServer to stop its polling behavior before the test continues with its teardown, and everything’s a-ok now. Thanks for the pointer!

If you find yourself in a similar situation, here is what worked so far:

1. Run mix test --trace to see which test file has the test that triggers this error
2. Put a setup block on this test file with on_exit(fn -> :timer.sleep(1000) end). This will give sometime between the test runs. Since on_exit runs in another process, the test process will be able to finish normally.
3. Run mix test test/app_name/problematic_test.exs --trace

This will show the DBConnection error right below the problematic test.
Also, since this is an intermittent error, it’s also useful to run the file multiple times with something like:

$ for i in {1..10} do; mix test test/app_name/problematic_test.exs --trace done