Can't use Task.async within LiveView?

exjutsu · July 9, 2020, 6:15am

I’m hoping you can help me to understand a strange issue that I’m experiencing. I’m going through some of the tutorials on the Pragmatic Studio for LiveView and in one of the lessons it illustrates updating the page using :timer.send_interval(1000, self(), :tick) to trigger a handle_info(:tick, socket) call.

The example in the course works just fine, but I wanted to try triggering a handle_info function after some async work had completed, so I tried triggering a Task.async within another button click event that would send pid, :tick at the end of the task…this is where things went sideways. Even if I just try to run a Task.async(fn -> IO.puts "Task running" end) the moment that the task is triggered I get this error:

** (FunctionClauseError) no function clause matching in MyAppWeb.MyAppLive.handle_info/2

Is there something that prevents Task.async from working within a :live_view?

I feel like I’m chasing the wrong problem and that there’s a better way to do what I’m trying to do, which is to have some type of user action trigger a few async and then let the interface update as each task completes.

Any help you can provide would be greatly appreciated.

NobbZ · July 9, 2020, 6:18am

A task will always send a message to its creator when it finishes. If I recal correctly, it follows the form {task_id, return_value}, perhaps that one is causing the error? You sadly haven’t shown us the full error message, as well as you haven’t shown us some code how exactly you do it.

ityonemo · July 9, 2020, 6:33am

You have three options:

the liveview doesn’t directly care about the result of the task or you will take care of sending a result manually (via call, or, in your example by sending directry). In this case use Task.start_link or better, Task.Supervised.start_link instead of Task.async. So this is probably your best option.
you care about the result but will handle it in the body of the same block where you issued the task. Then you need to catch the result with Task.await. I don’t think this is what you are looking for.
you care about the result but you want to catch the answer outside of the function block. Then you must catch the response message with a handle_info clause. Liveviews don’t come with one by default but it is a valid callback. Guidelines are the same as gen_server (but mind that the liveview handle_info take a socket instead of state): https://hexdocs.pm/elixir/Task.html#async/3-message-format. I think what is happening is that Task.async is trying to send the message back to your liveview, but you don’t have a catchall handle_info, like:

def handle_info(_, socket), do: {:noreply, socket}

so what happens is it triggers function clause not found when the Task.async shoots back its response.

exjutsu · July 9, 2020, 7:02am

I was about to post some code and error messages but when I went back and looked at it again, after your comment and you got me on the right track.

If I sent the result of Task.async(...) |> Task.await() the error goes away, so it sounded like the problem was really coming from what you exactly mentioned, about the Task trying to send a message back to it’s creator.

After that I had to add two handle_info functions to get the errors to stop.

One in the format that you mentioned:

def handle_info({_task_id, _return_value} = task_info, socket) do
  IO.inspect(task_info)
  {:noreply, socket}
end

# Returns: {#Reference<0.2773227633.484966403.150753>, "Finished"}

And then I also needed another in this format:

def handle_info({_, _, _, _, _} = details, socket) do
  IO.inspect(details)
  {:noreply, socket}
end

# Returns: {:DOWN, #Reference<0.2773227633.484966404.152877>, :process, #PID<0.1204.0>, :normal}

NobbZ · July 9, 2020, 8:15am

A catch all handle_info/2 should also always log at least a warning. Not explicitly handled messages can hint on leaking messages.

ityonemo · July 9, 2020, 2:38pm

So that second one is because task.async I guess is taking out a monitor on the async process. TIL but I guess it makes sense!

github.com

elixir-lang/elixir/blob/1145dc01680aab7094f8a6dbd38b65185e14adb4/lib/elixir/lib/task.ex#L423


The reply sent by the task will be in the format `{ref, result}`,
where `ref` is the monitor reference held by the task struct
and `result` is the return value of the task function.
"""
@spec async(module, atom, [term]) :: t
def async(module, function_name, args)
    when is_atom(module) and is_atom(function_name) and is_list(args) do
  mfa = {module, function_name, args}
  owner = self()
  {:ok, pid} = Task.Supervised.start_link(get_owner(owner), get_callers(owner), :nomonitor, mfa)
  ref = Process.monitor(pid)
  send(pid, {owner, ref})
  %Task{pid: pid, ref: ref, owner: owner}
end

@doc """
Returns a stream where the given function (`module` and `function_name`)
is mapped concurrently on each element in `enumerable`.

Each element of `enumerable` will be prepended to the given `args` and
processed by its own task. The tasks will be linked to an intermediate

I personally don’t like to use Task.async in fully remote catching mode, so I recommend Task.start_link for most concurrent tasks.

egze · July 9, 2020, 3:35pm

You should demonitor the process in the first handle_info

Process.demonitor(ref, [:flush])

Supamic · December 1, 2023, 6:49pm

I just wanted to post this shorter ElixirConf talk and accompanying github repo this for anyone else landing her looking for more recent information on this topic because I found it very useful.