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

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?

@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.

You can use put_private Phoenix.LiveView — Phoenix LiveView v1.2.5 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.20.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.

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

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?

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?