exjutsu

exjutsu

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.

Showing Posts 1 to 7

NobbZ

NobbZ

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

ityonemo

You have three options:

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

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

  3. 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): Task — Elixir v1.20.2. 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

exjutsu OP

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

NobbZ

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

ityonemo

ityonemo

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!

https://github.com/elixir-lang/elixir/blob/1145dc01680aab7094f8a6dbd38b65185e14adb4/lib/elixir/lib/task.ex#L423

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

egze

You should demonitor the process in the first handle_info

Process.demonitor(ref, [:flush])

Supamic

Supamic

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.

— All posts loaded —

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
kpanic
Hi everyone, I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding. I sta...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
asweet-confluent
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
apz
I’m new to elixir and just tried to install the elixirLS extension for VScode(ium) and it is throwing some errors that I would like help ...
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
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
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
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

Latest on Elixir Forum

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews