Long, synchronous running code in application initialization


I need to run some code (including database drop and recreate) for a staging setup. This has to be done after the application supervisor is initialized, because some children are required to be alive before this long code is ran (K8S probes).

The rest of the children of the top supervisor must not be started before the initialization code has ran, because those children will use data setup by this code.

So I cannot use a Task here, as the execution is asynchronous. I abused a GenServer’s init/1 callback to run the code:

defmodule SyncTask do
  use GenServer

  def child_spec(opts) do
    case opts[:id] do
      nil -> super(opts)
      id -> Supervisor.child_spec(super(opts), id: {__MODULE__, id})

  def start_link(opts) do
    GenServer.start_link(__MODULE__, Map.new(opts))

  def init(%{once: true, id: id, call: f}) when id not in [nil, :undefined] do
    pkey = {__MODULE__, id}

    case :persistent_term.get(pkey, nil) do
      nil ->
        :persistent_term.put(pkey, :ran)

      :ran ->

  def init(%{once: true}) do
    raise ArgumentError, "the once: true option requires the :id option to be set"

  def init(%{call: f}) do

And so I use it like this in when starting the application supervisor:

@impl true
def start(_type, _args) do
  children =
      {SyncTask, call: fn -> before_start() end, once: true, id: :before_start},

  opts = [strategy: :one_for_one, name: MyApp.Supervisor]
  Supervisor.start_link(children, opts)

It seems to work well, but I guess it is not really idiomatic. What would you do?

Unless I am misunderstanding your usecase, his can be done async. You’re task or genserver has the ability to run the databse init, then after it is finished it can add the dependent processes to the supervisor using Supervisor.start_child/2. This will avoid the use of persistent term or ets for coordination. The async Task or GenServer can be added to the supervision tree as well, to ensure that it runs successfully and retry on error. This could be a good use of a DynamicSupervisor, but if the processes are static (only kicked off once at startup), maybe a regular Supervisor will do the trick.

1 Like

I’d keep the approach that you’ve used since it actually seems you need a synchronous init.

1 Like