Fire & forget Task from Phoenix controller

TLDR: what’s the difference between Task.Supervisor.async_nolink and Taks.start, and which one I should call in Phoenix controllers, please?

Full story:

I have read several threads here and several blogposts on using simple Tasks, and would like to solidify my understanding

I understand you shouldn’t use Task.async if you don’t need to Task.await.

In those situations, it seems like I should use either Task.Supervisor.async_nolink which has the benefit that it’s not linked to process that started it (in my case e.g. the phoenix controller process that dies too soon and would take down this task with it), but you are still able to supervise it and handle failures if I got that right. (For which you’d need a GenServer to handle that?).

Another option seems to be Task.start which docs say only used when the task is used for side-effects (i.e. no interest in the returned result) - so is this one the truly simplest fire & forget? Not linked with anything, no idea whether it succeeds or not, not particularly important?

Example of my specific use case: I have a simple todo list, and when users check any of the todos, I want to run a background check whether all his todos are finished and send an email if yes - all of this can happen in the background without the user knowing, maybe only me as admin should see the failure somewhere in logs.

Just a note: I am not looking for a library, which probably exists. I’d like a pure elixir solution in order to learn and understand first.

Thank you!

1 Like

You’re right that both Task.Supervisor.async_nolink and Task.start are not linked to the current process, that’s often what we want. The difference is the former is linked to the task supervisor. This means when the application goes down, your task will be properly cleaned up too. In the case of Task.start because it’s not linked to anything, it may be left dangling.

3 Likes

This response to a different but similar thread might answer your question:

2 Likes

I usually create a named task supervisor in the applications supervision tree. This makes it easier to leverage observer to keep an eye on their execution.

2 Likes

Thank you all for additional explanation and links. Makes perfect sense to have a supervised Task rather than unhinged one flying around!

Hmm, seems like I actually have to run Task.Supervisor.start_child in my case. This approach is mentioned here https://hexdocs.pm/elixir/Task.html#module-dynamically-supervised-tasks

When I try Task.Supervisor.async_nolink, I actually get error that I have undefined handle_info function. The documentation here https://hexdocs.pm/elixir/Task.Supervisor.html#async_nolink/3-compatibility-with-otp-behaviours states the following:

If you create a task using async_nolink inside an OTP behaviour like GenServer , you should match on the message coming from the task inside your GenServer.handle_info/2 callback.

Keep in mind that, regardless of how the task created with async_nolink terminates, the caller’s process will always receive a :DOWN message with the same ref value that is held by the task struct. If the task terminates normally, the reason in the :DOWN message will be :normal .

So is the start_child the real fire & forget one? @wojtekmach @wolf4earth @harmon25

Ah, yup! If you don’t intend to await you shouldnt async_nolink either, start_child is the way to go.

3 Likes