No function clause in Wallaby.SessionStore.handle_info (:EXIT)

[djthread]

Hello! I'm just starting to get into writing some Wallaby tests again and I'm getting this error after the test passes.

15:10:20.485 [error] GenServer Wallaby.SessionStore terminating
** (FunctionClauseError) no function clause matching in Wallaby.SessionStore.handle_info/2
    (wallaby 0.28.0) lib/wallaby/session_store.ex:81: Wallaby.SessionStore.handle_info({:EXIT, #PID<0.1398.0>, :normal}, %{ets_table: :session_store})

Modifying SessionStore to ignore the message seems to be a solution, but I don't understand the whole situation.

  def handle_info({:EXIT, _pid, :normal}, state) do
    {:noreply, state}
  end

[mhanberg]

When you see this, are you experiencing failing tests? Or just a stray error in the log?

Also, can you share your Elixir, OTP, and OS version?

[vladimir-o-razuvayev]

Hey @djthread did you ever resolve this? I'm setting up Wallaby tests myself, and even with passing tests I still get this genserver error in the logs.

macOS Sequoia Version 15.3.1
Elixir 1.18.2 (compiled with Erlang/OTP 27)

[standard-adam]

This was a bit long ago now. I don't really recall how it went, and I'm not currently using Wallaby. Sorry.

[vladimir-o-razuvayev]

Oh well, thanks for the reply though.

So this seems to be happening because session store is trapping exits and the port to the chromedriver is crashing? My Phoenix project is running within nix compose, so I wonder if that is causing issues since my chromedriver and chrome are outside of the nix environment? Alternatively, why is SessionStore trapping exits?

On its turn, the port will send the connected process the following messages:
...
{:EXIT, port, reason} - exit signals in case the port crashes. If reason is not :normal, this message will only be received if the owner process is trapping exits

[mhanberg]

I'll take another look

[vladimir-o-razuvayev]

So I managed to fix this for myself. Nothing to do with nix, but by ensuring each session was closed at the end of my tests with a end_session/1 call, it went away.