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.

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

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.