Phoenix Liveview using Task.Supervisor.async_nolink vs PubSub for a long worker

Phoenix Forum Questions / Help
1

I have a long task I need to run to basically compute something realtime as a user scrolls a PDF. What is the best way I should be structuring my calling code for the external api? I started off using async_nolink but I noticed that it seems I can’t name the tasks and there are timeout issues unless I modify the supervisor config. Would using PubSub be appropriate for this usecase? Just begin the external api call from the liveview handle_event and then when the task is completed, send a notification to the PubSub which broadcasts to the liveview. I do not want to block my UI if the task takes too long. In addition, If the user initiates a new demand, I would want the previous one to be abandoned / ignored.

2

I would expect that the live view would hold onto the return value of Task.async_nolink which will include the pid. You could certainly name this pid, but I don’t quite see the point, since the live view will already have a handle to the task.

Can you show your current code?

3 
@impl true
  def handle_event("triggering_event", params, socket) do

    Task.Supervisor.async_nolink(Some.Supervisor, fn ->
      {:ok, res} = LongApiCall.run() 
      {:result, res}
    end, timeout: 30_000)

    {:noreply, socket}
  end

  @impl true
  def handle_info({ref, {:result, res}}, socket) do
     socket = assign(socket, some_key: res)
    {:noreply, socket }
  end

I’ve noticed the task always sends back to the calling process (the live view) a message upon completion and then upon termination of the task (the termination is always the “DOWN” event).

But ideally I would like to be able to handle_info as if the task was sending a message with a specific key that I could match on and respond to. Otherwise, how can I keep track of the task’s pid unless I add it to the socket.assigns (somehow it feels like assigns should be for client side to-render items and not for tracking workers).

I noticed in the book “realtime phoenix” a library called GenStage is used after introducing channels.

4

You can use put_private Phoenix.LiveView — Phoenix LiveView v0.20.14 for this since you don’t need change tracking. It also wouldn’t be particularly weird to put it in the assigns, as you might drive some UI behaviour to indicate that a background task is in progress.

Task.Supervisor — Elixir v1.16.2 has some examples of integrating async_nolink with handle_info.

Ultimately you need to store the task ref because it’s the most reliable way to detect crashes too.

2 Likes
5

An other option might be using async assigns like shown here:

1 Like
6

These async assigns on the Phoenix documentation is great, wish it was made more prominent or easier to have found (I guess it is a relatively newer feature).

Also, at what point is the use of a GenServer / seperate module for managing workers warranted vs bare tasks within the liveview callbacks?

1 Like
7

When to use a GenServer vs tasks is something that has been discussed quite a few times already on the forum, so I’d look for some of these discussions to get a full answer.

But if you look at the documentation of Task

Tasks are processes meant to execute one particular action throughout their lifetime, often with little or no communication with other processes.

So 1 action => Task. If you need more complex interactions, you can probably reach for a GenServer.

Another thing to take into account is how you want to manage the lifecycle of the async process. Does the process need to die when the liveview dies or not?

1 Like