@venomnert,

Even though this code might work for your current use case you have to consider what happens if one of the tasks crashes.

With this code, if one task crashes, your GenServer will also crash with your state because the Task is still sending the GenServer a message that is currently not handled. You can handle them as follows:

   def handle_info({:EXIT, _task, _reason}, state) do
     IO.puts("Crashed!!!!!")
     {:noreply, state}
   end

  def handle_info({:DOWN, _ref, :process, _pid, reason}, state) do
    IO.inspect(reason)
    {:noreply, state}
  end

The first message will have the tuple {:EXIT, task, reason}. The other one is {:DOWN, _ref, :process, _pid, reason}. You already have a tuple similar to this one but handles the happy path when the task exits normally like this {:DOWN, _ref, :process, _pid, :normal}… note the :normal atom at the end will be pattern matched.

With this in place, your GenServer will not crash and will be available to handle other tasks.

So this might work but: I just wanted to share with you some recommendations @whatyouhide gave us during this weeks ElixirConfLA in Medellin.

He recommended us:

1. Limit the amount of tasks that can be spawned to avoid exhausting the resources

2. Use the proper strategy for your use case:
   a. one_to_one
   b. one_for_all
   c. rest_for_one

   So what happens if one of the task fails? is it worth continue processing the other tasks? how will your state be affected if one task fails?

   Check this link for details of each one: https://hexdocs.pm/elixir/Supervisor.html#module-strategies

3. Nest you supervision tree with other supervisors with the proper strategy. For example, under your main application supervisor, create a worker supervisor with a one_for_one strategy.

4. All processes should be supervised

5. Name your supervisors to access them by name which is easier.

6. Test you supervision tree

I will be monitoring when the talks are published to link it to this thread.

Best regards,