Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stubbing a Req.Request in a Phoenix.LiveView.assign_async #429

Open
davydog187 opened this issue Nov 9, 2024 · 5 comments
Open

Stubbing a Req.Request in a Phoenix.LiveView.assign_async #429

davydog187 opened this issue Nov 9, 2024 · 5 comments

Comments

@davydog187
Copy link

Disclaimer: I will note that this is an "advanced" use case which may not be solvable, but I wanted to have a discussion first.

Hello @wojtekmach, thank you for your amazing library, I love Req!

This issue is to determine if there's a possible solution for testing a Req.Request inside of async LiveView assign. Imagine the following live view (btw I can totally appreciate that this might need a change in LiveView but I'll start here if thats ok)

defmodule MyApp.Live do
  use Phoenix.LiveView
  
  def mount(_, _, _) do
    {:ok, assign_async(socket, :foo, fn -> {:ok, Req.get!("http://something.com").body} end)}
  end
  
  def render(assigns) do
    ~H"""
    <.async_result :let={foo} assign={@foo}>
      <%= inspect(foo) %>
    </.async_result>
    """
  end
end

The problem here is that in order to test this LiveView and stub out the call to Req.get!, there is a race condition, as the request to the LiveView will have already been made before you get the pid back that you can call Req.Test.allow/3` against.

e.g.

test "assync_assign with a Req.Request", %{conn: conn} do
  {:ok, live, _html} = live(conn, ~p"/my-route")
  
  # Race condition as `Req.get!` may have already run
  Req.Test.allow(MyApp.Req, self(), live.pid)
  Req.Test.stub(MyApp.Req, fn conn -> Req.Test.json(conn, %{}) end)
end

Of course, this could be solved with some sort of conditional that uses environment config, or a mocking library like Mox or Mimic.

However, I'd like to imagine there could be another way to propagate ownership so that the allow could be called prior to the LiveView creation. This may require changes to LiveView, it might be impossible, or it might not be something you want to support.

Thanks for the consideration and feel free to close if this is something you are not interested in supporting

@davydog187
Copy link
Author

I suppose this generalizes to GenServers that call Req in init/1 or a handle_continue/2 from init, so the mention of LV is maybe not necessary

@zachallaun
Copy link
Contributor

Mox allows you to pass a function to allow in case you need to delay evaluation of the allowed pid. Could something like this work?

parent = self()

Req.Test.allow(MyApp.Req, self(), fn ->
  send(parent, {:allow, self()})
  receive(do: (pid -> pid))
end)

{:ok, live, _html} = live(conn, ...)

assert_receive {:allow, pid}
send(pid, live.pid)

This is a little clunky. It means that, if a function is passed, it needs to be run in its own process to prevent deadlocks, but perhaps a pattern like this could work? It could be wrapped in a helper to make it a bit more ergonomic.

@davydog187
Copy link
Author

Another solution would use telemetry events to hook into the process

@wojtekmach
Copy link
Owner

Yeah speaking of telemetry events, we have this Broadway guide: https://hexdocs.pm/req/Req.Test.html#module-broadway

I think it is fine when people do that in their own GenServers and Broadway pipelines which I’d considered intermediate level but this is too much for people using LV so we should definitely improve this. Since Ecto sandbox works in LV we should have infrastructure in place to make that happen. Or it does in LV but not in async assigns? In any case, yes, this is definitely a priority and any help is appreciated.

@wojtekmach
Copy link
Owner

Wait, this seems to work already? https://gist.github.com/wojtekmach/2ee023315dd6ea209d67b6d3ef8cd985

Could you modify the snippet to show the bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants