mbklein

Intermittent DBConnection.ConnectionError in tests

When running my tests, I sometimes see an error that looks like

[error] Postgrex.Protocol (#PID<0.788.0>) disconnected: ** (DBConnection.ConnectionError) client #PID<0.7569.0> exited

Notable details:

It doesn’t always happen
When it does happen, it’s not always in the same test or test file
It doesn’t actually cause any tests to fail; it just shows up as output in the middle of the output like so:

image1209×233 6.75 KB

I’ve been ignoring it up to this point because the test suite still passes and it hasn’t caused any development or deployment bottlenecks, but I’d like to figure out why it’s happening and what I might be able to do to stop it.

Version details, in case it matters:

Postgres v10.19 via the postgres:10-alpine Docker image
postgrex v0.16.1
ecto v3.7.1
ecto_sql v3.7.2
ecto_psql_extras v0.7.4

Any thoughts?

29 comments

#postgrex #ecto_sql

1 4776 29

2025-10-12 21:48:42 UTC

Marked As Solved

danturner

Heya,

not sure if you’re still having the issue…

the error means that a db query is live when the test is torn down,

in our case it was due to some of our liveview tests clicking a submit button that caused a push_patch to happen in a live_component rather than the parent liveview,

for some reason LiveViewTest will wait for the patch if it happens in the parent process before returning, but not if it happens in a child component,

you can force it to wait by doing an assert_patch, or calling any of the functions that use the view object

not sure if that helps you, but thought i’d add it as it was a little confusing

i raised an issue here LiveviewTest render_submit behaves differently if form is in parent liveview or child live_component · Issue #2579 · phoenixframework/phoenix_live_view · GitHub as the behaviour feels inconsistent

Post #9

Also Liked

mbklein

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.

Post #17

al2o3cr

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.

Post #2

talkignquickly

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.

Post #8

Last Post!

Schultzer

Yeah, not sure myself. Hopefully I can eliminate some of these issues in my library, since I found out I can’t use db_connection, although the pool I’m building can be specialized and more optimized then db_connection ever could be, so looking forward if there is gonna be found any root causes to these issues other then write your code differently.

Post #30