How to run function on startup that blocks execution?

Your solution of calling the function before passing the children to Supervisor.start_link is totally reasonable, and is what Sentry does to set up its’ Logger backend. However, you’ll need to make sure that whatever lib you’re using to make the HTTP request is started before you make the call! Req might do this for you automatically (guessing yes) but I know Finch won’t, as it must be started by the client app.

Thanks, good to get some confirmation on my approach. In my case, it should be fine – I’m doing some more complex RabbitMQ setup that gets a little hard to follow if it’s strung across so many Broadway pipelines and their :after_connect arguments.

However, that is an interesting point… sometimes you need certain things started in order (like the HTTP client example). Is there any way to ensure an ordered startup like that (with blocking)?

Yup! Check this out: Application — Elixir v1.20.2

Ah… hmm… I’ve only used that in Mix tasks. Would Application.ensure_all_started/2 work to ensure specific children had been started?

E.g. if Worker2 required Worker2 to be started, could you do

children = [
  Worker1,
  Worker2
]

and inside Worker2:

def start_link(_args) do
  Application.ensure_all_started(Worker1)
end

?

I’d say this is more of a smell than anything. Your applications shouldn’t be coupled in that way, and if they are, then Worker2 should be having Worker1 in its’ application.ex

There are two main approaches to this. One is to do whatever you need to do in the application start/2 callback which you’ve already discussed. This is good if you need to do something before any process has started.

If you need some parts of the application to be started (e.g. Ecto) then you’ll need to add a process to your supervisor that performs the setup after the needed processes are started but before the processes that require the setup step.

I use the latter approach to ensure all Ecto connections have been established before moving on to starting something like Oban. What I’ve done is created a transient GenServer that performs the blocking work in the init/1 callback. This will halt the supervisor start process until the work in init/1 has finished. Once the work in init/1 has finished I return :ignore to prevent the GenServer from starting and continue on with starting the remaining processes.

Whether this is a code smell or not I’ll let you decide.

Here is some example code.

defmodule MyStartupProcess do
  use GenServer, restart: :transient

  def start_link(_opts) do
    GenServer.start_link(__MODULE__, :ok)
  end

  @impl true
  def init(_) do
    :ok = do_setup()

    :ignore
  end
end

I think this should work, as you can return :ignore right from the start MFA:

defmodule OnStartup
    def child_spec(_) do
      %{id: __MODULE__, start: {__MODULE__, :startup, []}}
    end

    def startup() do
      do_something
      :ignore
    end
end

And then just add OnStartup to the list of children in your application.ex depending on when you want it to run

I think you should either just do something in an init callback of your own GenServer or just use a handle_continue in it – assuming that the latter will not leave your app in an inconsistent state until your own init code succeeds.

You wouldn’t want to use handle_continue in this case because handle_continue will explicitly not block startup, although in my experience most of the time you actually don’t want to block startup. But this thread is specifically about the times that you do want to block startup.

Yeah I get this, and I am questioning the need to block startup. But it’s also true that it’s more complex to have both: (1) not block startup and (2) not have your app in degraded state, so maybe blocking startup really does save time and effort.