dbaer

dbaer

Hey all, it’s time for Yet Another DB OwnershipError :tm: thread!

I’ve been working through @germsvel’s fantastic TDD Phoenix Book, but I’ve applied modern testing facilities and options (i.e. Wallaby.Feature), Verified Routes, Phoenix LiveView and German’s own PhoenixTest library, and have run into some problems when I added a database store for my sessions.

I went with database sessions to skirt around the fact that LiveViews cannot modify the cookie based sessions directly, and I’m experimenting with a fully LiveView auth setup.

I currently use this technique in a production application, but instead it uses stock testing methods as well as PhoenixTest, and about 20 times as many feature tests.

Unplug the database sessions from the test bench and voila, it works.

I’m really scratching my head here as my test bench is not so different in configuration from the production app, other than using Wallaby.

Basically, I’ve setup the tests as Wallaby’s documentation suggests for Phoenix and LiveView:

endpoint.ex

if sandbox = Application.compile_env(:chatter, :sandbox) do
  plug Phoenix.Ecto.SQL.Sandbox, sandbox: sandbox
end

socket "/live", Phoenix.LiveView.Socket,
    websocket: [connect_info: [:user_agent, session: @session_options]],
    longpoll: [connect_info: [:user_agent, session: @session_options]]

config/test.exs

config :wallaby,
  driver: Wallaby.Chrome,
  otp_app: :chatter

config :chatter, :sandbox, Ecto.Adapters.SQL.Sandbox

test_helpers.exs

{:ok, _} = Application.ensure_all_started(:ex_machina)
{:ok, _} = Application.ensure_all_started(:wallaby)

Application.put_env(:wallaby, :base_url, ChatterWeb.Endpoint.url())

on_mount hooks for LiveView:

def on_mount(:default, _, session, socket) do
  allow_ecto_sandbox(socket)
end

defp allow_ecto_sandbox(socket) do
  %{assigns: %{phoenix_ecto_sandbox: metadata}} =
    assign_new(socket, :phoenix_ecto_sandbox, fn ->
      get_connect_info(socket, :user_agent)
    end)

  Phoenix.Ecto.SQL.Sandbox.allow(metadata, Application.get_env(:chatter, :sandbox))
end

feature_case.ex (RTXasync on by default)

using do
  quote do
    use Wallaby.Feature
    use ChatterWeb, :verified_routes

    import Chatter.DataCase
    import Chatter.Factory

    use ExUnit.Case, async: true
  end
end

And of course, a test! This issue is causing all tests to fail but here is an example:

test "user can create a new room successfully", %{session: session} do
  user = build(:user) |> set_password() |> insert()
  params = params_for(:room)

  session
  |> visit(~p"/")
  |> sign_in(as: user)
  |> click(Query.link("New Room"))
  |> fill_in(Query.text_field("Name"), with: params.name)
  |> click(Query.button("Save"))
  |> assert_has(Query.data("role", "title", text: "Chatting in #{params.name}"))
end

where sign_in/2 is just some more Wallaby actions as outlined in the TDD Phoenix book.

The stack trace for the ownership error points right at my session plug:

    (ecto_sql 3.11.1) lib/ecto/adapters/sql.ex:1051: Ecto.Adapters.SQL.raise_sql_call_error/1
    (ecto_sql 3.11.1) lib/ecto/adapters/sql.ex:952: Ecto.Adapters.SQL.execute/6
    (ecto 3.11.2) lib/ecto/repo/queryable.ex:232: Ecto.Repo.Queryable.execute/4
    (ecto 3.11.2) lib/ecto/repo/queryable.ex:19: Ecto.Repo.Queryable.all/3
    (ecto 3.11.2) lib/ecto/repo/queryable.ex:154: Ecto.Repo.Queryable.one/3
>>  (chatter 0.3.0) lib/chatter/account/session.ex:53: Chatter.Account.Session.get/3
    (phoenix 1.7.11) lib/phoenix/socket/transport.ex:495: Phoenix.Socket.Transport.connect_session/3
    (phoenix 1.7.11) lib/phoenix/socket/transport.ex:481: anonymous fn/3 in Phoenix.Socket.Transport.connect_info/3
    (elixir 1.16.2) lib/enum.ex:1700: Enum."-map/2-lists^map/1-1-"/2
    (elixir 1.16.2) lib/enum.ex:1700: Enum."-map/2-lists^map/1-1-"/2
    (phoenix 1.7.11) lib/phoenix/socket/transport.ex:463: Phoenix.Socket.Transport.connect_info/3
    (phoenix 1.7.11) lib/phoenix/transports/websocket.ex:48: Phoenix.Transports.WebSocket.call/2
    (chatter 0.3.0) lib/chatter_web/endpoint.ex:1: ChatterWeb.Endpoint.do_socket_dispatch/2
    (chatter 0.3.0) lib/chatter_web/endpoint.ex:1: ChatterWeb.Endpoint.plug_builder_call/2
    (chatter 0.3.0) lib/chatter_web/endpoint.ex:1: ChatterWeb.Endpoint.call/2
    (bandit 1.3.0) lib/bandit/pipeline.ex:103: Bandit.Pipeline.call_plug/2
    (bandit 1.3.0) lib/bandit/pipeline.ex:24: Bandit.Pipeline.run/6
    (bandit 1.3.0) lib/bandit/http1/handler.ex:33: Bandit.HTTP1.Handler.handle_data/3
    (bandit 1.3.0) lib/bandit/delegating_handler.ex:18: Bandit.DelegatingHandler.handle_data/3
    (bandit 1.3.0) /home/dbaer/chatter/deps/thousand_island/lib/thousand_island/handler.ex:411: Bandit.DelegatingHandler.handle_continue/2
Last message: {:continue, :handle_connection}

which is this hairy hack job:

def get(_conn, sid, _opts) do
  query =
    from(s in Session,
      where: s.key == ^decode(sid)
    )

  case Repo.one(query) do
    %Session{} = session ->
      if Timex.before?(Timex.now(), session.expiry) do
        data = Map.put(session.data, "id", session.id)

        {sid, data}
      else
        sid = put(nil, sid, %{}, nil)
        get(nil, sid, nil)
      end

    nil ->
      sid = put(nil, sid, %{}, nil)
      get(nil, sid, nil)
  end
end

Naturally everything works as expected when running without async enabled.

I’ve tried a few things, including what I use in the production app:

setup do
  :ok = Sandbox.checkout(App.Repo)

  identity =
    insert(:identity, roles: [build(:account_role, role: build(:system_role, name: "ROOT"))])

  {:ok, session: build_authed_session(identity), identity: identity}
end

though I don’t use the pre-built users in the test bench. I’ve also tried some variations without Wallaby.Feature, as suggested by José in previous issue threads:

setup tags do
  pid = Ecto.Adapters.SQL.Sandbox.start_owner!(Chatter.Repo, shared: not tags[:async])
  on_exit(fn -> Ecto.Adapters.SQL.Sandbox.stop_owner(pid) end)

  metadata = Phoenix.Ecto.SQL.Sandbox.metadata_for(Chatter.Repo, self())
  {:ok, session} = Wallaby.start_session(metadata: metadata)
  {:ok, session: session}
end

Somehow the session store is operating outside of the connection process where everything else works, though I’m not sure how that’s possible.

Are there any further avenues to probe? I’m investigating using Wallaby in said production app, but I fear the tests will take an untenable amount of time to run in non-async mode.

Thank you!

Showing Posts 1 to 1

dbaer

dbaer OP

I poked around some more and it appears that my issue is the session store logic is getting called before the on_mount hook in my LiveViews.

I suppose a better question to ask is, is it possible to call allow_ecto_sandbox at an earlier stage of the lifecycle, before the session store is called?

— All posts loaded —

Where Next? Top

Trending in Questions Top

stjefim
Hello! Suppose you are building workflow (order / task / payment) processing system with the following requirements: Each workflow con...
New
jonnycharles
I’m in search of an Elixir library that offers PDF generation capabilities similar to Ruby’s Prawn. While there have been discussions abo...
New
spammy
I’m looking to build a personal workflow to quickly deploy web applications written in elixir/phoenix, for local consumption (ie not on t...
New
dli
Before I dive in myself, did anyone successfully sprinkle Hologram into their existing LiveView app? Looking for hints regarding: Addi...
New
roeland
Kia ora, We have been using elixir-google-api to connect to Google Drive. However, with the updates to Tesla due to CVEs this is now bro...
New
bottlenecked
Hi all, I wanted to ask how the community is dealing with post-release steps. Today we have Ecto migrations, which make sure that the db...
New
rahultumpala
Hello, I have an Elixir backend that implements a custom protocol over TCP. I want to load test the backend and assess the performance o...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
ausimian
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews