I’ve found this common pattern to cause ConnectionError in passing tests:
# flaky
assert view
|> element("#some-button-id")
|> render_click()
|> follow_redirect(conn, "/destination/path")
# better
view
|> element("#some-button-id")
|> render_click()
assert_redirected(view, "/destination/path")
I’ve created an issue here: Intermittent DBConnection.ConnectionError in tests · Issue #3545 · phoenixframework/phoenix_live_view · GitHub
I think you’re misunderstanding the comment you replied to. They’re saying that they’re doing something common which shouldn’t cause an error but does cause an error. I don’t think they’re saying that that the pattern will fix the error.
Hey all, we’re having the same problem. As suggested in the referenced issue Intermittent DBConnection.ConnectionError in tests · Issue #3545 · phoenixframework/phoenix_live_view · GitHub we were having async tasks fire off in Liveviews that made db accesses but the tests didn’t wait for them. render_async(view) is what fixed it.
Except we’re still seeing those errors for some of the tests. They don’t always appear (yay concurrency!) but when they do we have no inkling which tests logged those errors.
render_async(view) everywhere - but they’re still there, so maybe these aren’t liveview tests triggering this?mix test --trace - but that changes the test behaviour completely (runs everything serially as far as I can tell) so the error output never shows up in there.So I was wondering.. has anyone ever figured out a good solution for dealing with this? I would even be open to a hack, e.g. patching up ExUnit locally to print test filenames but couldn’t figure how to do that only when there’s some error output in the console.
Yeah, this is one of the more annoying things working with db_connection, the lack of visibility. If you browse the Github repo there is even an issue where connections are created and maybe dropped. It’s even harder to debug by looking at the code.
Do you have a lot of test that talks to the database with expensive queries?
There can be some slow queries I guess but the test db holds no data (except whatever gets setup per test which is then of course rolled back), so I wouldn’t think that that might be the case there
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.