Laetitia
[error] MyXQL.Connection (#PID<0.265.0>) disconnected: ** (DBConnection.ConnectionError) owner #PID<0.567.0> exited
Hi everybody,
i have an issue with my test suite. When i run each test separatly, everything is ok but in the whole test suite i have some DBConnection issues, althought all test pass.
Here is my case:
I have a Supervisor (a module that use Supervisor). This supervisor starts a scheduler. It is a genserver polling the DB periodically.
In the test, i start_supervised! this supervisor and do a few assert. But i get the following error:
MyXQL.Connection (pid<0.265.0>) disconnected: ** (DBConnection.ConnectionError) owner pid<0.567.0> exited
Client pid<0.572.0> is still using a connection from owner at location:
:prim_inet.recv0/3
(myxql) lib/myxql/client.ex:171: MyXQL.Client.recv_packets/4
(myxql) lib/myxql/connection.ex:102: MyXQL.Connection.handle_execute/4
(ecto_sql) lib/ecto/adapters/sql/sandbox.ex:370: Ecto.Adapters.SQL.Sandbox.Connection.proxy/3
(db_connection) lib/db_connection/holder.ex:316: DBConnection.Holder.holder_apply/4
(db_connection) lib/db_connection.ex:1255: DBConnection.run_execute/5
(db_connection) lib/db_connection.ex:1342: DBConnection.run/6
(db_connection) lib/db_connection.ex:595: DBConnection.execute/4
(ecto_sql) lib/ecto/adapters/myxql/connection.ex:28: Ecto.Adapters.MyXQL.C
....
The Client pid<0.572.0> is my scheduler and the owner is the test process.
As i read in the Ecto.Adapters.Sql.Sandbox, it seems to be normal: the test exits, the DBConnection lose its owner and notify the client process it doesn’t have owner anymore. But… the scheduler is querying the DB and is waiting for a reply. (Ecto.Adapters.SQL.Sandbox — Ecto SQL v3.14.0)
I would like to know how to prevent such errors (too many red in the screen ;( )
Also, start_supervised is aimed to start the process under the test supervisor and the lifecycle of the test process is:
- the test process is spawned
- it runs
setup/2callbacks - it runs the test itself
- it stops all supervised processes
- the test process exits with reason
:shutdown -
on_exit/2callbacks are executed in a separate process
(ExUnit.Callbacks — ExUnit v1.20.2)
It seems that my scheduler is still alive after the process exit. Why it is not killed with my supervisor at step 4?
thank you for your responses
Marked As Solved
al2o3cr
It’s sent a message requesting a shutdown in step 4, but based on the error message the scheduler process is waiting for a reply from the DBConnection process. Even shutdown has to go through the message queue.
The core of a solution to this is ensuring the scheduler isn’t blocked before shutting down; sending any synchronous message will force the test process to wait until your scheduler process is handling messages. For instance, calling :sys.get_state(scheduler_name) will work
Also Liked
ityonemo
Conceptually everything looks good. Can you show us the body of one test?
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









