An Elixir-flavored solution to this problem could look something like:

• the steps of load are done in a GenServer per “app”, started when a user pushes the “Load” button
• those workers are managed with a DynamicSupervisor and named using a Registry
• checking the status for an app’s “Load” button is checking to see if there’s a process registered
• (optional) if you want a load to stop when a user navigates away, your “Listing Apps” page could be a LiveView and the “Load” worker could monitor it & exit if no longer needed
• to update the button status in realtime, the worker should send a PubSub message, then the Liveview that’s rendering the button can subscribe and update

A followup question to think about: if the “Load” steps take more than a couple seconds, what should happen if the server wants to shut down while a load is running? You may need to adjust application + supervisor options to give things long enough to finish cleanly, or you’ll have to deal with partially-complete loads.

To offer another option, I think your idea of using the database is a good approach, especially if you ever plan to distribute your app across multiple nodes.

Instead of using Task.async, you would start tasks under a supervisor using Task.Supervisor.start_child/2 so that they survive under the supervisor even if the LiveView process dies (and so that they don’t block the LiveView - perhaps counterintuitively, you still have to await tasks started with Task.async).

In order to guarantee that the work is only done once, you should perform your processing checks inside the task. You also need to be careful to use a lock on the initial check to ensure there are no race conditions because Postgres (and other relational dbs) do not use SERIALIZABLE isolation by default.

For example:

Task.Supervisor.start_child(MyApp.TaskSupervisor, fn ->
  query = where(Thing, id: ^thing_id, processing: false) |> lock("FOR UPDATE")
  {:ok, thing} = Repo.transaction(fn ->
    case Repo.one(query) do
      %Thing{} = thing ->
        Repo.update! Ecto.Changeset.change(thing, %{processing: true})
      nil ->
        raise "Thing already processing!"
    end
  end)
  work = do_work(thing)
  Repo.update! Ecto.Changeset.change(thing, %{work: work, processing: false})
end)

Note that this code doesn’t handle failures, which is not trivial depending on your use case. If it’s okay to do the work more than once (as long as it’s only updated once), you can do the locking at the final update (or use Ecto’s optimistic_lock/3). You could also use a timeout to say when it’s safe to retry (if you need at most once within a time frame), assuming you trust your clocks.

LiveView processes are just GenServers, so you can literally just send a message back to the LV and accept it in handle_info.

lv_pid = self()
Task.Supervisor.start_child(MyApp.TaskSupervisor, fn ->
  # do work...
  send lv_pid, {:work_complete, thing_id}
end)

If you need to update the page for multiple users, then you would use Phoenix PubSub.

It’s perfectly fine. Obviously you should write to the DB as little as possible, but in this case two is the best you can do.