Set initial state for process on start/restart

I came up with this:

defmodule BootstrapExample do

  def start_link do
    IO.inspect MyApp.Repo.get!(MyApp.User, 2)
    MyApp.IntervalServer.start_link
  end

end

And stuck it in my supervision tree with worker(Bootstrap, [])

I can verify the call to the Repo on start and restart, which means I’ll be able to
meet my requirements.

It feels rather thin, am I opening myself up to any issues with the supervisor or
is there a better/more elegant way to achieve this?

Strictly speaking, you can fetch your timer list in the init/1 function of your IntervalServer, eg:

defmodule IntervalServer do
  use GenServer
  # ...
  def init(:ok) do
    timers = MyApp.Repo.all(MyApp.Timer)
    {:ok, timers}
  end
  # ...
end

..and you’ll have the timers in your state. The drawback of this approach is that your database access is holding up the application startup sequence, and the application will utterly fail to start if the database isn’t available.

A different approach is to have init/1 return {:ok, [], 0}, which means it initializes with an empty array of timers, but a timeout of 0 milliseconds. When the timeout expires (immediately after startup), handle_info(:timeout, state) will be called, and you can load your state in that callback instead, without hindering the application during startup.. Eg:

defmodule IntervalServer do
  use GenServer
  # ...
  def init(:ok) do
    {:ok, [], 0}
  end

  def handle_info(:timeout, []) do
    timers = MyApp.Repo.all(MyApp.Timer)
    {:noreply, timers}
  end
  # ...
end

It depends on what your needs are. Doing it with timeouts, though, is the “friendliest” option – you can probably indicate in some other manner that the application isn’t ready yet, than having it fail to start at all. Perhaps some functionality is still useful, even without the database being (temporarily?) unavailable, etc.

NOTE: The IntervalServer can just be started in the top-level supervisor at this point, if you want to, eg. lib/my_app.ex in the start/2 function, as a worker.

Thanks! I’ve added the timeout, works nicely!

Just a thought on extending your approach, would Process.send_after/3 be a good idea?
In lieu of relying on the :timeout message (despite my process not using other timeouts at the moment).

Do you see any risks in this:

  def start_link do
    {:ok, pid} = GenServer.start_link(__MODULE__, [], [name: __MODULE__])
    Process.send_after pid, :started, 0

    {:ok, pid}
  end

  def handle_info(:started, []) do
    # TODO: go fetch some data
    {:noreply, state}
  end

To be clear, both the start_link as well as init will block the start of the application. The supervisor will call start_link on the module which then synchronously waits for init to completely. So whether you’re putting the code in start_link or init it’ll still block the supervisor until it’s done.

Of course.. but since we’re just returning from init, with a hint for GenServer to send us a timeout, the actual work (in handle_info) will occur outside of the sequential startup sequence.

Should be fine too

As far as I can tell though, still best practice to do it from within init (which is executed in the context of the new GenServer process), eg:

def init(:ok) do
  Process.send_after(self(), :started, 0)
  {:ok, []}
end

def handle_info(:started, []) do
  # ...
end