** (DBConnection.Error) owner #PID<> exited while testing async function

In manual mode, the sandbox works with Task behind the scenes to ensure that the task process gets allowed to share the connection with the caller.

HOWEVER

That means that the task cannot outlive the test process, or you’ll get the error you’re seeing.

A quick way to check if this might be causing your issue would be to add Process.sleep(5000) or similar to the end of the test that’s failing. That will ensure the call to send completes before the test does.

@al2o3cr Do you have advice about the best way to handle this in a test? I’ve got some code that uses Task.start to call some side effect functions that I don’t care about the results of. But my tests that uses the parent function are returning this error now, because the Task is trying to outlive the test.
Is the best way to insert Process.sleep/1 statements? Or is there a better way?

I’ve been fighting this exact same problem in some of the tests in a project at work. I’m not using the Task API, but I see the same problem when testing GenServers and with some async LiveViews.

Our current approach is to have our tests safely kill the spawned process, and to ensure it has stopped before the test ends. The reason for this is that the fundamental problem is that the spawned process is killed while it is still expecting to receive data from the Postgrex process – which rightly complains when the process on the other end disappears.

I’d love for this to be easier, but right now we need to spend a lot of time identifying which tests are failing, and then building custom ways to ensure our process is either stopped cleanly or isn’t in the middle of a query.

Nowadays we have proper abstractions in place so this doesn’t happen as often.

First, for managing connections, make sure you are using the start_owner API: todo_trek/test/support/data_case.ex at main · chrismccord/todo_trek · GitHub

When you are starting processes under test, use start_supervisor! from ExUnit, which guarantees it will be shut down before the test process.

Finally, if you are starting tasks or processes under a supervisor dynamically, add an on_exit callback that gets all children of said supervisor and wait for them to terminate. Something like:

on_exit(fn ->
  for {_, pid, _, _} <- DynamicSupervisor.which_children(YourSupName) do
    ref = Process.monitor(pid)
    assert_receive {:DOWN, ^ref, _, _, _}, :infinity
  end
end)

When searching for start_supervisor! in the docs I get no results: Search — ExUnit v1.20.2!

Sorry, we couldn’t find anything for start_supervisor!.

I suppose you mean start_supervised!/2 ?

Yep, that’s the one.