Tasks are really not the right kind of thing to have running for a long time, you should use a genserver instead.

However to your specific question, id is not the value used to set the name, you need a name option, but I’m not even sure if tasks take a name option.

Indeed, Task.start_link/3 does not allow for something like the :name option.

https://hexdocs.pm/elixir/v1.10/%20/Task.html

Process.register/2 should work. But yeah. At the point where you have a stateless datastructure receiving messages inside a task, it’s time to use gen_statem. If you prefer a genserver like interface and enforced state graph on top of gen_statem, I wrote StateServer library for this purpose.

Otoh, if you’re doing this for fun and exploration of otp I highly encourage it!!

use Task, restart: :permanent

seems not right, IMO. I don’t think statefulness/not statefulness is the right way to think about whether or not you should use a GenServer vs. a Task. There are times where I have GenServer equivalents with state nil.

I would say a GenServer is supposed to be a service, and a Task is supposed to be an action. If you speak a romance language, GenServers are imperfective and Tasks are perfective. Tasks IIRC are a creation of Elixir to give OTP a sane default way to supervise simple things with strictly internal control flow, but as soon as you’re doing message passing to interface with a task, you’re in GenServer territory.

If you are having a Task that is permanent, it must somehow be responding to a message (probably a receive block?). Although that might work for now, I would suggest changing that over to a GenServer call. If for no other reason than the caller will know if the somehow the GenServer is unavailable. Even if all your call does is reply :ok and performs a {:continue, info} to actually do its thing. That will let the GenServer manage your message queue instead of doing it manually. This is good because you’ll get solid error warnings (the calling GenServer will crash), and you’ll also get backpressure management.

If your needed throughput for your service starts go get really high, you’re going to want to do process pools, and buliding out a process pool from a GenServer is a well-trodden, battle-tested, and relatively formulaic process; doing so with a Task I suspect could be challenging.

As stated, :gen_statem has a concept of event timeouts, where the timeout will be automatically cancelled if an event is received before the timeout expires. You create an event timeout by returning an “event timeout” action from a callback

{state, data, [:timer.seconds(5)]}
# or
{state, data, [{:timeout, :timer.seconds(5), value_to_include_in_callback}]}

Alternatively, if you want control over when the timeout is cancelled, you can use a generic timeout. As long as you keep returning the same generic timeout name from callbacks, then the timeout will keep being reset (or you can explicitly cancel it), otherwise the timeout expires and the process will receive a message about it.

{state, data, [{{:timeout, :my_name}, :timer.seconds(5), value_to_include}]}

GenServer also has builtin timeout support that can be used to detect inactivity:

def handle_info(:timeout, state) do
  dbg("5 seconds of inactivity have elapsed")
  {:noreply, state}
end

def handle_info(_, state) do
  {:noreply, state, :timer.seconds(5)}
end

And, if you want to be in control over when the timeout is cancelled, you can do so with Process.send_after/4 and Process.cancel_timer/2:

def handle_info(:timeout, state) do
  dbg("5 seconds of inactivity have elapsed")
  {:noreply, state}
end

def handle_info(_, state) do
  if state.timer, do: Process.cancel_timer(state.timer)
  state = put_in(state.timer, Process.send_after(self(), :timeout, :timer.seconds(5)))
  {:noreply, state}
end